Интересува ме дали линукс има надеждна файлова система и на
коя да се спра?

 Въпроса почива на опита който имам с редхат + ext3 и редхат
+ reiserfs.

 В продължение на 10 месеца при 15 server-a имахме 8 проблема
със загуба на файлове или цяла система.

 Проблема възниква обикновенно след спиране на тока в момент
на писане във файл.

 Искам да отбележа, че става дума за натоварени server-и
работещи с бази от данни.

 За същия период от време и при същите условия имахме 18
 NT/2000 + oracle без нито един случай на загуба на
файлове/данни.

От тук следва и нашия проблем.
Вариантите са 2:
 1. Ние не можем да настройм файловата система както трябва.
 Това е напълно възможно, защото не променяме default
настройките след инсталация.

2. Linux не притежава качества за production OS.

 Ползваните от нас версии на linux са redhat 7.3 и redhat
9.0.

 Моля да пращате само мения които почиват на реален опит в
 натоварени системи, а не на слухове или неща които са дочути
 от някъде (или на принципа - е, това е linux и не може да
бъде).

Още да отбележа, че системите са от тип 7/24.

Благодаря предварително.

 Не, бе, няма надеждни файлови системи, които да се поддържат
от линукс ядрото.
 То сигурно факта, че на повече от 2/3 от сървърите по света
 има именно такива файлови системи, сигурно се дължи на
масово умопомрачение.

 Личният ми опит с 2003 стандарт едишън е ... а бе много
зле.
 Сигурно не съм дорасал да настройвам сървър с разни
 чекбоксове и падащи менюта. Явно е много сложна операция. А,
бе, знам ли? Един ден с 2033 ентърпрайз едишън....

 Интересно, защо питате тук? Достатъчно сериозни сайтове има
 из нет-а, предлагащи статистики и анализи по интересуващите
ви въпроси.

 Да не би да ви тормози факта, че сте дали куп пари за
 МС-софтуер и не получавате това, което сте очаквали? Или вие
 сте от тези привърженици, които никога не плащат
комерсиалния софтуер и само претендират неоснователно?

 При РедХат не е важно каква файлова система ще ползваш, а
 час по-скоро да си смениш ядрото и да не ползваш това, което
ти идва с дистрибуцията.

 Но твоя случай много ме учудва щото твоя опит е много
плачебен.

За аа:
 Действително се опитваме да съберем максимално информация о
въпроса.

Постнали сме го и в доста други форуми по света.

Като не знаеш нещо по-добре не коментирай.

Личния ти опит с 2003 не ме интересува.
 Ако имаш личен опит в много натоварена линукс среда, които
да споделиш си добре дошъл с менние.
 Опитваме се да изясним, дали проблема е в линукс или сме
изпуснали нещо в настройките му.

Към drandran:

Имаш ли конкретна идея защо да сменя ядрото и с какво?

 няма проблем да сменим дистрибуцията, стига да е ясно къде е
проблема.

 Избрахме redhat, защото започнахме с ext3, а тя се прави от
 тях. Предполагахме, че са най-наясно какво правят. След това
пробвахме reiserfs, със същия успех.

Пробвай с някое от последните от (www.bg.kernel.org)
2.4.21 или 2.4.22.

 Не казвам че РедХат е лоша дистрибуция, просто не ползвай
тяхното ядро.

 Основаната причина да не ползваш ядрото от дистрибуцията е
 че се добавят нови неща, които често не са изтествани
 достатъчно. Като пример е "Сусе 9.0" хората са се постарали
 да го пипнат но има бъг в ядрото за к7 и ако си с reiserfs
ще се изпатиш. Е пуснаха кръпка на 14.11.
Иначе RedHat + ext3 + Oracle трябва да е добър избор.
Успех

С redhat и ext3 ни започнаха проблемите.
 След спиране на тока обикновенно ни вкарва като root и иска
да си пуснем fsck ръчно.

Следват много въпроси дали да fix-не нещо или не.

 По някога успява да се оправи, но много често файловете
 остват повредени (т.е. в тях няма инфомацията която се
очаква).

 Това беше главната причина да започнем да ползваме reiserfs.
Резултата е сходен поне при нас.

 Иначе по-принцип не гледаме оптимистично на смяната на
адрото.
 Все пак се очаква тези от redhat да разбират много по-добре
от нас как да се настрой дадено ядро с файловата система.
 Най-малкото ако някой си мисли, че е по-наясно направо да ги
пита за работа.

Можете ли да пуснете тук fstab-а, защото имам подзрение, 
че не сте си настроили правилно нещата. Това, което е по 
подразбиране, не е добро. Щом ви вкарва в fsck, значи 
наистина нешо сте оплескали и точно това fsck ви омазва 
нещата.

Да,
при нас е последната система която се drop-на преди ден.
За съжаление е с reiserfs.
 Тези с ext3, почти ги сменихме (т.е. сложихме resiserfs) и
не са при нас.
 /dev/hda2               /                       reiserfs
defaults        1 1
 /dev/hda1               /boot                   reiserfs
defaults        1 2
 none                    /dev/pts                devpts 
gid=5,mode=620  0 0
 none                    /proc                   proc   
defaults        0 0
 none                    /dev/shm                tmpfs  
defaults        0 0
 /dev/hda3               swap                    swap   
defaults        0 0
 /dev/hdc2               /mnt/diske              reiserfs
defaults        1 2

~
 Ако някой може да прати fstab след нормална инсталациа на
redhat ще помогне.

 Да допълня, въпроса съм го пратил и на разработчиците на
reiserfs и за мое очъдване има пълно мълчание за сега.

 Shtom imate tolkova mnogo serveri, tip 7/24 i gonite
 kachestva na production OS napravo e smeshno da niamate
UPS-i!
 Mnogo e prostichko da si predstavi chovek - v momenta na
 zazapisvane spirat tocite i baitovete ne se zapisvat kudeto
triabvat, shtoto hdd-to e sprialo da se vurti :)
 Dori da ne ti se razbrichka file-ovata sistema ili
 avtomatichnia check primerno na reiserfs da mine bez nikakuv
 problem,  sled tova veroiatnostta в тях da ima инфомацията
която се очаква, ne e mnogo goliama.
 Kupete si ups-i, ne se izlagaite da slizate v dvijenie ot
avtomobil, koito se dviji s 200 km/h.

Не всички са съгласни да си вземат UPS-и.
 Разбира се ги съветваме до го правят, но не можем да ги
накараме.

 Само да отбележа, че машините спират не само заради тока, а
да речем поради кофти захранване или нещо изгоряло и т.н.

Така, че проблема си остава.

 Това което искаме да направим е да заменим Windows/oracle за
места където не можем да ползваме backup на данните.

 За тези места си има UPS, никой не е сигурен за изгоряло
 захранване или токов удар или нещо такова. По тази причина
 ни трябва сигурна файлова система. А отговорността при
писане по диска е точно на файловата система, а не на HW.

 Да, грешно са описани файловите системи. Когато имате
журнал, накрая редът трябва да завършва с 0 0. Когато има 
срив, при рестартиране файловата система се  
възстановява,  като превърта журнала, което става за 
секунди. В случая обаче, вместо да превърти журнала и да 
се възстанови, се включва програмата fsck, която е за ext2 и 
се забърква в цялата работа. На практика, вие изобшо не 
ползвате журналните възмозности на системата. Когато
ползвате журнална файлова система, слагайте накрая
0 0, за да не се пуска fsck, защото иначе на практика нищо 
не правите. Впрочем, тези неща ги има описани в доста
документация.

Ще търсим информация по въпроса допълнително.

 На пръв поглед съм притеснен какво ще прави журнала при
различни конфигурации от типа на writeback и т.н.

Имате ли реален опит с тези опции с 0 0 ?
И разбира се представа какво става с тях.

На практика не можем да си позволим експерименти.

Po-goliama glupost ne biah chuval!!!
man fsck:
 "....In  actuality,  fsck  is  simply  a  front-end for the
 various file system checkers (fsck.fstype) available under
Linux....."
root@slack:/sbin# ls /sbin/fsck*
 /sbin/fsck       /sbin/fsck.ext3  /sbin/fsck.minix 
/sbin/fsck.reiserfs
 /sbin/fsck.ext2  /sbin/fsck.hpfs  /sbin/fsck.msdos 
/sbin/fsck.umsdos

 Abe chetete malko predi da iztropate niakoia prostotia
tuk!!!

Към Abuser_:
Няма проблем.

 Ясно беше, че се е объркал, но може би има нещо в идеята за
0 0.

Abuser, не усещаш ли, че си малко арогантен?

 Изобщо не съм се объркал. Представи си, че /sbin/fsck е
 симлинк, който води към fsck.ext2 и като се стартира, се
опитва да поправи дял с reiserfs. Резултът е ясен - боза.

 Нямам време сега да се впускам в подробности. Имаше една
 статия от руски, която преведох преди време тук, но тя се
 загуби след един проблем със сървъра. Там беше добре от
 компетентни хора. Просто fsck няма работа при ext3 и
 reiserfs - как, защо и т.н. и при кои случаи се намесва е
друга тема.

 pp, ако искаш, пиши ми на мейла, довечера ще имам време и
може да обменим опит.

 Edin burz pogled pokazva, che fsck ne e bilo, NE E i sigurno

 nikoga niama da byde symlink. Za svedenie fsck poluchava s
-t 
parametyr filesystem type. (Neznam zashto ne obichate da  
chetete man pages, ako ne mojete da chetete idete v 
 nai-blizkoto osnovno uchilishte). A i naistina e meko kazano

naivno da se tvyrdi, che nadejnostta na edna file sytem se 
 osnovava na polzvaneto na ekvivalentite na liubimia vi
scandisk 
 ot Windows, kakto Nikola liubezno (i ne chak tolkova) se
opitva 
 da ni ubedi, iskaiki s 0 0 opcii v /etc/fstab da si
izkliuchim fsck. 
 Dano pone ot obmianata na opit da ima polza i pp da prestane

da prevryshta foruma v izdanie na v-k. Styrshel kato pishe 
citiram "otgovornostta pri pisaneto po diska e tochno na 
 failovata sisitema a ne na HW" - pp, choveche, gotov sym da
ti 
podaria edin bugav HDD da si go polzvash s niakoia 
 neizmislena oshte file system, koiato zapisva pravilno
vsichko.

 Към Никола - ако говориш за тази статия "Журналната
 файловата система ext3" то тя не се е загубвала. Може да я
видиш в Статии->Съвети->Файлови системи:
http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&cmd=cat&cid=fs

За freshmeat:
  Не получих никаква смислена информация от това което си
написал.

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

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

 Та при това положение се очаква, че след като данните са
 подадени към файловата система от даден продукт, и след като
 файловата система е потвърдила записа ( в случая рабоим с
 fsync) то данните са на диска и при следващо прочитане ще са
точно такива каквито са били записани.

 Дано да ти е ясно от какво значения за всяка реално работеща
система е това.

 Ако не ти е ясно, моля те не пречи на други който имат
желание да помогнат да си кажат мнението.

Цитат от Abuser_:
"Shtom imate tolkova mnogo serveri, tip 7/24 i gonite
 kachestva na production OS napravo e smeshno da niamate
UPS-i!"
- МНОГО си е прав човека.
Цитат от pp:
 "Само да отбележа, че машините спират не само заради тока, а
да речем поради кофти захранване или нещо изгоряло и т.н."
 - няма значение поради каква причина е спрял тока, дали
 АЕЦ-а е гръмнал, дали някой мангал е одрязъл кабела - спре
ли тока - UPS-а сработва!
 Изобщо защо го водите този спор.Имал съм случей Windows 2000
 AS Domain Controler след спиране на тока изобщо да не се
 стартира, данните в него липсваха а да не говорим за
 течащата репликация по това време.Друг  подобен случей имам,
 на домашното Desktop PC (linux 2.4.20 reiserfs). След
 спиране на тока не можах да си възтановя никакви данни на
 reiserfs дяла. ... така, че и на windows и на linux се слува
това.
Ако сте в 7/24 режим, UPS-а е задължителен.

/dev/hda2               /                       reiserfs
defaults        0 0
 /dev/hda1               /boot                   reiserfs
defaults        0 0
 none                    /dev/pts                devpts 
gid=5,mode=620  0 0
 none                    /proc                   proc   
defaults        0 0
 none                    /dev/shm                tmpfs  
defaults        0 0
 /dev/hda3               swap                    swap   
defaults        0 0
 /dev/hdc2               /mnt/diske              reiserfs
defaults        1 2

и ...................................SYNC :)))

bye 
успех

а ето ти моят FSTAB 
 # Device                Mountpoint      FStype  Options     
   Dump    Pass#
 /dev/ad0s1b             none            swap    sw          
   0       0
 /dev/ad0s1a             /               ufs     rw          
   1       1
 /dev/ad0s1f             /tmp            ufs     rw          
   2       2
 /dev/ad0s1g             /usr            ufs     rw          
   2       2
 /dev/ad0s1e             /var            ufs     rw          
   2       2
 /dev/acd0c              /cdrom          cd9660  ro,noauto   
   0       0
 proc                    /proc           procfs  rw          
   0       0
ps: tova e na FreeBSD 4.9

Hi ,
 hwurlih edin pogled nad tazi diskusia i reshih i az da se
obadq :))
 Znachi az lichno podurjam weche blizo godina (moje i malko
 poweche da e) 2 oracle server-a (i mnopgo drugi na koito
 nqma oracle де), tuk e mqstoto da otbeleja che e po malko ot
 NEMISLIMO tezi mashini da nqmat Ups-i. Tezi mashini sa v
 rejim 7/24/365.Blizo 50choweka rabotqt online s tqh. Kato
 distribucii polzwam linux -> RedHat 8.0 i dosega NIKOGA ne
 sum imal problem nito s filesystem-ata nito sus zahranwania
, nito s hardiskove nito s mangali :))) 
 Powecheto hora w tozi forum pisaha nai razlichni neshta s
 cel da se zaqdat (neznaino zashto , moje bi towa e edna ot
 osnownite cherti na tipichnia bulgarin) , e az ne go prawq s
takawa cel ... prosto spodellqm moq opit :))
 ta ... momcheta ako ste reshili da prawite takiwa neshta ...
 prosto e nemislimo da nqmate UPS-i :) taka si spestqwate nad
 99% ot problemite ot tipa "nepredwideni obstoqtelstwa"
 (spirane na toka i etc)... kolkoto do normalnoto sustoqnite
 na systemata -> ne se pritesnqwaite ... ext3 shte se griji
dobre za washite files :))))

Best Regards,
Danail Petrow

За дидо:

Благодаря за мнението.

Пак не е станало ясно.
 Под проблем със захранването разбирам проблем със
захранването на самия компютър (онова дето стой зад UPS-a).
 Те също се скапват от време на време и тогава файловата
система от голямо значение.

Иначе не споделям мнението, че ext3 ще се грижи за нещата.

Още да добавя.
 От reiserfs споделиха, че не могат да гарантират за решаване
 на този проблем (т.е. с целостта на данните). Отговорността
при тях е на ниво metadata.

 Съвета от там, е че може би ext3 са малко по-напред с
 материала, но и от там не можело да се очаква нещо
по-добро.

Това си е направо притеснително в момента.

 Следващата стъпка е да пиша и на тези дето правят ext3 за да
има и тяхното мнение.

 Също така се оказва, че freebsd са дост по-напред в тази
област.
Лошото при мен е, че freebsd не ми върши работа.

za pp:
 Problema koito opisvash izobshto ne opira do failova
 sistema, a do tova, che niakoi se e stisnal za malko pari za
 hardware, t.e. UPS, chitavi zahranvania na PC-tata. Ako pp,
 beshe se zamislil v/u tova koeto mu napisah shteshe da
 izvleche malko polza ot moia skromen post, kato razbere, che
 sys software (demek file system) hardware problems (tokovi
 udari, srivove, termo-iadrena voina) ne se reshavat. Kogato
 se govori za failovi sistemi po-logichno e da se ima
 vpredvid byrzinata i utilizaciata na diskovoto porstranstvo
 primerno - i za malkite deca e iasno che ako stane HW sriv
 niama failova sistema koiato da te spasi i da svyrshi
 rabotata za koiato niakoi ti plashta - a imenno da se
 garantira rabotata na server-a plus celostta na dannite - za
 tova se praviat backup-i polzva se ogledalen RAID masiv i
 t.n. Ako mojeshe podoben problem da se reshi s niakakva
 OS/filesystem, mnogo hora po sveta (vkliuchitelno i ti, pp)
 shtiaha da stanat bezraboni i shtiaha da sa operatori na
biologhichni edinici (prevod: ovchari).

За freshmeat:

Е очевидно имаме различия в преценката.

 Моето мнение е, че данните трябва да се намират на диска
 (разбирай във файловата система) във вида в който са били
подадени и потвърдени, че са приети.

 Ако това не работи никакъв mirror (RAID 5 или RAID 10) не
могат да те спасят.

 Предполагам, че никога не си се опитвал да правиш backup
(online) на система 7/24.

 Има случай в които трябва да разчиташ на 100% на OS +
 файловата система, защото и загубата на последните 5 мин. не
може да се оправи.

 Аз не се притеснявам за работата си, ако системата работи
 безотказно, защото работата ми е да правя software, а не да
 се занимавам с изследване на лошо направени файлови
системи.

 Изглежда всички тези проблеми са накарали oracle да
 игнорират файловата система на дадената ОС и да си направят
собствен формат.

 Благодаря за опита да помогнеш, макар и да не е решение на
проблема.

Hi,
 Znachi az lichno ne sum fan nito na ext3 nito na RedHat ...
 prosto mi se nalaga da gi polzwam. S izkliuchenie na
 Database serverite si , wsihcki drugi serveri koito prawq sa
 na Slackware i rabotqt s reiserfs... NO... da ti kaja chesno
 wse oshte nqma chitaw util za fix na failed reiserfs dokato
 za dobroto staro ext3 fsck (nqkoi tuk moje da kaje "ami to
 si ima i reiserfsck" a az da mu otgoworq -> opitai se ti da
 si fix-mnesh reiserfs s towa :)) si wurshi dobre rabotata.
 Shte ti kaja kakwo mi se sluchi naskoro .. i weche imam
 malko po raazlichen mirogled .. na edna mashina s 1.7TB info
 (slackware 9.0). Znachi towa e mashina s okolo 18HDD-ta ...
 1 ot tqh (reiserfs) neshto mu stana ...kernel-a zapochna da
 pliue razni stranni neshta w syslog-a i w sledwashtia moment
 kogato reshih da si izkopiram dannite ot tozi disk i da gi
 prehwurlq na drug hdd poluchih suobshtenieto "permission
 denied" a bqh kato root? :) sled malko rowene iz google se
 okaza che towa e problem na reiserfs vuzniknal sled
 bad-reboot .... nqma da produljawam da goworq za towa
 zashtoto ne mi se zadulbochawa w towa ... anyway .. ot
 togawa sum malko abstrahiran kum reiser i se nadqwam po
 skoro da izleze reiserfs 4.0 (pishe dosta obeshtawashti
nestha ) -> http://www.namesys.com/v4/v4.html

best regards,
dido

Здравей РР,
 Аз лично нямам опит със системи 24-7-365 (и никога няма да
 имам), но имам опит с изгорели захранвания и то много горчив
 - вервай ми! Да не би захранванията на сървърите ви да са
 JCN, Codegen, Linkworld, KME, Super Power и т.н. поздрав от
слънчев Шанхай :( 400 китайски вата :(
 Ако е така - веднага ги сменете с нещо от рода на: Q-tec,
 Seasonic, Enermax, Chieftec, Antec - доста по скъпи са, но
 си струват всеки лев отгоре. Това се отнася особено за
натоварени машини, където информацията няма цена!
Успех!
П.П. Към админите на сайта:
 Махнете го това зелено табче за клавиатурата, че само бърка
кирилицата. Много е кофти.

За Nuclear_man ,
По принцип слагаме или искаме да има хубави захранвания.
 Слагаме кутии за по 150-170 USD, но се случва да има
проблем.

 Нещата имат развитие, защото дрес получихме предложение от
reiserfs suppor да си платим и те да изследват проблема.
 Преди тива имахме съобщение, че reiserfs не може да
гарантира данните.

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

 Така като ми изглежда май не са наясно изобщо и се опитват
да отговарят каквото и да е.

 До тук единственото разумно нещо което може да послужи за
 основа за работа е да се опитаме да спрем write cache на IDE
дисковете.

 По принцип не знаем как се справи и ще започнем да четем по
въпроса.

kym Plamen:
 syshto i kym wsichki deto postoqnno natqkwat za tez UPS-i
..
 momcheta tolkowa li ne mojem da shwanem che ne stawa wypros
za 100 ili za 200$ za UPS ?!? wyprosa e principen ..