Надежна ли JFS?

[Eugene Gorbunoff]

e-co:

Какой вывод из всего этого? Нужно написать на сайте программы бэкапа:

1) Step 1: Check your drives,
chkdsk x:
fix all problems
2) Step 2: After every heavy hang or crash of system perform chkdsk again.



froloff:

chkdsk как правило не может устранить повреждение JFS.
Единственный вариант - скопировать все файлы на другой диск и
отформатировать JFS заново.

3) Ни в коем случае не хранить важные файлы на загрузочном JFS!!!


Glassman:

Все так плохо? А почему тогда не шли в направлении hpfs386? Она ведь вроде более отлажена и с кэшами там проблем нет...


Digi:

>> 3) Ни в коем случае не хранить важные файлы на загрузочном JFS!!!

чёйта? только голая практика: кучка почтовых серверов (+ кэши проксей), у всех по одному разделу, соответственно, активное обращение с постоянным чтением/записью, винты мрут раньше ФС.

> Все так плохо? А почему тогда не шли в направлении hpfs386? Она ведь вроде более отлажена и с кэшами там проблем нет...

тормоз, проблема больших файлов, ТОРМОЗ при чекании больших разделов на этапе загрузки.


froloff:

> чёйта? только голая практика: кучка почтовых серверов (+ кэши проксей), у
> > всех по одному разделу, соответственно, активное обращение с постоянным
> > чтением/записью, винты мрут раньше ФС.
> >

Только голая практика!


>> >> Все так плохо? А почему тогда не шли в направлении hpfs386? Она ведь вроде
>> >> более отлажена и с кэшами там проблем нет...
> >
> > тормоз, проблема больших файлов, ТОРМОЗ при чекании больших разделов на
> > этапе загрузки.

* более устойчива под нагрузкой и к сбоям.
* держит ACL
* дать побольше памяти - будет быстрее чем JFS,

но

* стоит отдельных денег (идёт только в составе LanServer)
* максимальный размер тома 64Гб (ограничение реализации, а не самой FS),
* максимальный размер файла 2Гб (аналогично)
* нет журнала, дольше загружается и chkdsk для больших томов может длиться сутками.