Linux за българи: Форуми

Здравейте,

В последните няколко седмици се интересувам от файлови системи. Тествах доста, но резултатите са много противоречиви. Може ли да кажете, коя файлова система ползвате и защо?

За мен критериите на които трябва да отговаря са:
1. Производителна с малки файлове т.к. не дърва много големи файлове
2. Трябва бързо да минава "ремонта" за това reiserfs не я смятам за добър вариант.

Като се надявам да не давате линкове към бенчмаркове, а да споделите опит ;-)

Преди ползвах reiser3 и бях доволен. След като гръмна хард диска преди около година реших да пробвам ext3 и в момента ползвам само нея като разлика в произоводителността изобщо не усещам. Сложил съм и journal flag с пуснат dir_index и си работи та пушех се дига. Направих прехода главно заради поддръжката, която очаквам от създателите на файловата система, а именно хакерите на ядрото. Най - големият ми дял /torrents, който е пълен с филми е с xfs и нямам особени проблеми с нея, въпреки че се е случвало да се гаси компа директно от електроцентралата   . Четох, че била по - бързичка с големите файлове и затова съм я избрал за тоя дял, на който имам главно филми... Reiser4 и ext4, които се водят тестови не съм ползвал, но чух много хубави работи за ext4 . Давай смело към ext3 като си я настроиш - поне ще си сигурен, че поддръжката няма да падне :

Освен това XFS е много добра с много файлове и директории (стотици хиляди и милиони). Като за стабилност също бих препоръчал jfs, а за ощб тип цели ext3

Всичко хубаво, но аз го ползвам за малки и много хиляди файлове. Обаче при тестовете ми:
Първо, ext3 е по-бърз за малки файлове от XFS (като съм си поиграл с блоковете да е за малки файлове)
Второ, XFS без изнесен лог в отделен партишън чупи яко суперблока и не може да се ремонтира лесно. Иначе не мога да го счупя и да видя какво ще стане, за жалост
Трето, XFS при големи файлове примерно 1Г вади 2 пъти по-голяма производителност!
четвърто, JFS няма почти документация и е много грозна за научаване и заради това не съм я разучавал
Пето, ext3 се поправя за 5 часа, а reiserfs за толкова дни :-D

Други предложения или хубави идеи за оптимизация на ext3 и xfs ?

Прегледа ли какво са писали другите из форума по темата?

Цък 1

Цък 2

 

Kalin, както винаги добър източник на информация, но мене много горещо ме интересува не само производителността, но и времето за ремонт. Това е като в рали шампионатите - хем скорост, хем точки за ремонт

romeo_ninov, всичко от там съм изчел, но няма почти нищичко за тунинговане. Или може би много зле сравнявам т.к. с XFS може да правиш почти всичко и на всичките блокове да сменяш размера.

Впрочем с подмяната на размера на блока успявам да оптимизирам XFS за опреден диапазон размер на файловете. Като в проценти е около 10-15%, което не е малко - 45М/с си е бая

Хаха, напоследък ocfs2 vs gfs ми е страшно актуална тема Чак ме боли главата от 1-2 седмици насам

Апропо, защо толкова те вълнува времето за ремонт? Сега по-новите проекти за файлови системи между другото се опитват да правят online recovery, мисля че след не много време времето за "ремонт" няма да има голямо значение

gat3way, да онлайн може да се "ремонтира" xfs. Като е нужно само да е ro. Времето за ремонт ме вълнува т.к. е тъпо масива ми да се чеква 5 дена и машината да е down :-)

5 дена чек-ване? Нали има журнал, би следвало да е доста по-бързо.

Апропо, Sun имат друг подход - ZFS няма журнал, а прави чексума на всяка операция. Вярно, така се разхищава пространство и производителност, но пък fsck отпада като вариант.

gat3way, 5 дена rebuild tree на около 6Т :-D

6 терабайта е ужасно голяма файлова система, за да се намира на райд масив на някой x86 сървър и при това да има риск от спиране на тока Но аз съм разглезен предполагам

За UFS чували ли сте

пробвай и NTFS и ни информирай бива ли я...

ocfs2 е хубаво нещо и лесно се сетъп-ва. Работи чрез TCP връзки.

gfs е хубаво нещо ама не се сетъп-ва толкова лесно и прави разни много странни неща, които изглеждат нелогични, но просто принципа е малко различен, там един node fence-ва друг. Работи през мултикасти или специален шернат block device. Fencing-a е много странно нещо при тази файлова система, определено, хаха

По някакви много субективни наблюдения, gfs е по-бавна файлова система, ама не съм правил тестове и не знам.

gfs има много противни наклонности да не маунт-ва файловата система след ребуут, въпреки че е описано в fstab с _netdev, за разлика от ocfs, затва там се правят малко странни занимания за целта.

Имам и доста други наблюдения, като цяло съм очарован от цялата работа - не очаквах подкарването им да е такава тарапана

Edmon - скучен си?, малко трябва да дадеш exit на конзолката ми се струва

Ползвам, потърси за gat3way/Milen Rangelov :0

gat3way, gfs при мен си е вкарано в fstab и се монтира нормално при стартиране на машината...

/dev/blabla/gfspartition    /mountpoint         gfs     _netdev        0 0


Иначе идеята на RedHat ако се не лъжа е при ползване с RH Cluster Suite услугата, която ползва дяла, да си го монтира.

Да, през RHCS си правя такъв "ресурс" и услуга.

А не тръгва, защото шернатият block device е physical volume съответно с VG/LV-та вътре, при което за да се активират, трябва да се изчака да се вдигне clvm-a. Тъй като _netdev нещо не се разбира с clvm по въпроса, затова трябва или на ръка, или като услуга от RHCS, която да се вдига на нод-а.

Поне така мисля.

Абе всъщност не съм коректен...това не е проблем на gfs, по-скоро на това, че ползвам LVM върху шернато устройство. Значи грубо казано, експериментирам с 2 LUN-a експорт-нати от един storage по SAN-a. Виждам ги през 2 FibreChannel контролера, като за целта ползвам multipath. В крайна сметка имам 2 блокови устройства. Върху единия директно съм си изпльоскал ocfs файлова система, другия го направих PV и го понацепих малко, като резултатът е че виждам няколко блокови устройства през device mapper-a. Един от тях (да речем) го форматирам с gfs. Проблемът е че няма как без нещо да се съгласува с отделните нодове и да прави активацията на volume групите вземайки предвид останалите cluster members, това да върви нормално, защото в противен случай, при активацията на vg-тата от страна на един нод, върху блоковото устройство се пишат разни работи, другите нодове също ги виждат и става голяма каша. Затова има и clvm, който регулира нещата.

Лошото е че като дадеш _netdev във fstab, файловата система ще се маунт-не в момента в който се "появи" блоковото устройство и се заредят нужните модули. При мен така като гледам, device nodes си има създадени, но самите volume групи не са активирани (тези, които не са на локален диск)...при което монтирането на файловата система просто пропада. Просто скрипт-а, който монтира файлови системи и се възползва от това _netdev, не взима предвид clvm.

Така че не е проблем на gfs това, по-скоро на LVM-a. Предполагам, че ако си направя ocfs файлова система върху LV на някое шернато блоково устройство, проблемът ще бъде абсолютно сходен. Но не съм тествал още комбинацията ocfs2+clvm. Би било интересно

Защо не погледнеш VxFS (Veritas filesystem) има безплатна версия за Линукс на сайта на Семантек

Не искам

Майтапя се де, ама надали ще я пробвам, не зависи от мене..

За това сега съм с windows и нямам проблеми, гаден фанатизъм

Ох, исках просто да кажа, че нямам чак толкова свобода по отношение на моите експерименти с файлови системи в случая

Що се отнася до zfs, няма да ми спаси заниманията с ъъъм хардуерни неща, Освен това далеч не е клъстерна файлова система и точно заради това е неприложима в моя случай

Ами аз и в този случай не мисля за РАИД нива. Не администрирам сториджи, не им организирам нивата на redundancy, не определям на кого да се експорт-ват LUN-ове, аз само използвам

Що се отнася до шефовете ми не бих казал че са идиоти, които искат да изтискват пари от безплатни решения. Малко фирми имат по-голям ИТ бюджет в България, от нашата, определено

Въпросът е че няма как ей така да се вземе решение ей така на линукс машина да се слага Веритас, трябва да има фирма, която да го предложи, да осигури подръжка, ей такива работи. Бих казал, че има други неща, които са забавни в цялата тази работа, обаче не мисля, че мога да ги споделя

С малко повечко ентусиазъм ще намеря и лек за СПИН

Майтапя се де

gateway,

Интересно за какво ти трябва клъстърна файлова система. Можеш ли да изброиш изискванията?

За HA cluster. Трябва ми свестен failover на няколко услуги, при едната от тях е свързана със сервиране на разни файлове като целта ми е не да държи много заявки, а просто да не се случва да има downtime, защото последиците не са много приятни.

Клъстърният софтуер си върши работата да суич-ва пакетите по нодовете и да си прави heartbeat-a и проверката на услугите и стартиране/спиране по отделните машини. Но тези файлове трябва да се намират на споделена файлова система. Беше ми минала през главата една олигофренска идея да се държат локално и нещо (например rsync) да ги синхронизира...ама така да имаш консистентност на данните при отпадането на някой нод е просто прекалено сложна работа Освен това е супер неудобно..

А и лошото е че тези файлове могат да се пишат, не само да се четат от клиентите.

Не може и ще ти обясня защо е така.

Да речем че сървиса се изпълнява на една машина от клъстера. Файловете се държат в локална файлова система, ако ще на zfs, ext3, reiserfs, каквото и да било. Някакви скриптове синхронизират тези локални файлови системи през определен период от време, да речем на всеки 2 часа. Никой не ти гарантира, че тази машина няма да "падне" в един момент и сървиса да се суич-не да се изпълнява на друга такава. При това положение, всички качени файлове след последната "синхронизация" няма да се "виждат" от клиентите, а това ще докара една много голяма каша. При това контролните суми въобще не ме греят..

Не, не мога да споделя защо е

Иначе може и върху САН-а, обаче и там има проблем. Трябва да съм абсолютно сигурен, че когато маунт-вам на една машина файловата система, никоя друга машина не го е направила. Т.е при отпадане на interconnect-а примерно, пакета ще се суич-не, сървиса ще се вдигне върху друга машина, но нищо чудно да се случи така, че в един момент и двете машини са маунт-нали файловата система, което най-вероятно ще доведе до data corruption. Това предполагам може да се изработи, но отново като цяло, тарапаната става по-голяма отколкото да си подкарам клъстерна файлова система.

Не искам помощ, бе Ромео, и не рева, само си споделям проблемите 1-2 странички по-нагоре ме помолиха да си споделя опита  с тези файлови системи, това и направих.

Що се отнася до първата част на поста, не мисля да я коментирам Аз например не бих говорил неща, в които не съм много уверен, освен ако не съм на няколко големи водки естествено Аааа, обаче за оная фирма и за сериозните неща, вече съм лично засегнат, не те е срам Няма да пропусна да предам похвалите ти на тези специалисти от тази фирма де, за щяло и нещяло, често се виждаме с тях Обаче съм ти много обиден да знаеш

Както е тръгнало, ще се видим в началото на 2008 с някои от тях, най-вероятно. В последно време все ги тормозя за едни и същи неща, сигурно им е писнало вече от мене

Честно казано не мога да разбера какво ще подобри HA използването на споделен SAN, той пак си остава single point of failure и по нищо не се различава от добър сървър.

Всичко това можеш да го имаш и в добър сървър.

> П.П. @tarator, не искам да те засегна, но има един израз - когато
> атовете си ги мерят магаретата стоят настрани

Хайде да не ми даваш акъл какво да правя, да не се окаже, че атът съм аз, а вие сте магаретата. Много са ми забавни екземпляри като теб, които си мислят че ако някой не използва модерните думички, които те знаят, означава че не ги знае или не знае повече от тях.

Не си много сигурен, но съветваш тези които са да мълчат, нали?

> ти май по коледно си загубил чувството си за хумор

Чувството за хумор се проявява най-добре като го прилагаш върху себе си. Опитай.

> а и за кой ли път се убеждавам че у нас малко хора имат глобално
> мислене

Не съди за другите по себе си.

> Един ат никога не би си помислил че един сървър може да замени по
> отказоустойчивост няколко сървъра, работещи заедно

Абе, Ромео, затова ли за всички сериозни операции финансовите компании използват мейнфрейми? Не се излагай.

> Ох, ами то е така, колкото повече знаеш, разбираш колко малко знаеш.
> А не като някои, които дават ултимативни решения (един сървър,
> например)

Не ми слагай твои думи в моите уста. Попитах съвсем сериозно как използването на SAN, който също е SPF ще подобри HA на системата. Отговорът както се разбра е никак.

Ъ, весела коледа

Честита Коледа АТове хихихихи...
и анимационния герой да си пие по-често хапчетата!

> АМи аз дадох решението - два SAN-a, 4 връзки от един SAN до сървър,
> това малко ли е?

T.e. използването на (един) SAN по никакъв начин не подобри HA на системата, само ни принуждава да търсим HA решение на още един елемент.

И с какво това решение е по-добро от два сървъра с RAID и решение за синхронизиране на дисковете им?

Ромео, не показваш никакъв погед отгоре, а поглед как да изброиш и използваш максимален брой продукти на любимата си фирма. Поглед отгоре се проявява когато вместо рецитиране на рекламни брошурки, започнеш да си задаваш въпроси с какво всеки елемент от конфигурацията повишава нейното HA.

Както съм споменавал нееднократно аз съм професионалист и се стремя да не съм "привърженик" на една фирма. Подобни оферти (за САН и т.н.) се предлагат от немалко фирми, така че обвиненията в пристрастност са безпочвени. По повод НА явно всеки от нас гледа от различна гледна точка, защото за мен е важно не толкова всеки елемент да помага за НА, а комплекса като цяло да е такъв. Та аз гледам общото, ти отделните елементи. Без коментар....

П.П. Неприятно ми е НЕПОЗНАТИ да се обръщат към мен лично. Или се представи или използвай ника ми!!!

http://youtube.com/watch?v=VFyXlb26ihs

Сега кажете че не съм МНОГО гаден интригант ахах

romeo_ninov, kато ти е неприятно непознати да използват името ти, да не си го писал по форумите. Или ти е неприятно, че не се обръщам към теб с г-н Нинов? Щом толкова държиш, ще се представя, казвам се Мучно Подиговски. Може да ме наричаш Мунчо

> По повод НА явно всеки от нас гледа от различна гледна точка, защото
> за мен е важно не толкова всеки елемент да помага за НА, а комплекса
> като цяло да е такъв.

Не, ти добавяш нови елементи, на които след това трябва да им търсиш HA решение. И затова в решението ти, вместо два елемента/сървъра с една мрежа и два кабела от сървър, има _четири_ елемента с над 8 кабела. И защо? Защото ти е хрумнало да сложиш SAN в решение, което не е задължително да го изисква.

> Има методи с помощта на които можеш от нетолкова надеждни елементи
> да изградиш надеждна система,

Знам, че има такива методи, но един от принципите им е, да не се включват компоненти, които не са абсолютно необходими. Защото само усложняват системата.

Та ако ми беше отговорил нормално, вместо да се дуеш, сега нямаше да се оплакваш.

Съжалявам, че се намесвам, само че в моят случай са необходими. Обяснил съм защо.

gateway,

На теб ти трябва метод за синхронизиране (с някаква точност) на "представата" на два сървъра за файловете във файловата система. За това не е (задължително) необходим SAN.

Без да се знае точно какво е приложението е много трудно да се определи кое е най-подходящото решение. Колкото решението е по-общо, толкова по-трудно е да се реализира добре.