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 для больших томов может длиться сутками.