Re: [Comm] Holy wars: xfs vs reiser

[Gleb Kulikov <glebus@asd.iao.ru>]

В сообщении от Понедельник 16 Май 2005 16:21 Michael Isachenkov написал:
> А что вообще надежнее? собственно говоря, два критерия:
>
> 1) насколько часто при прочих равных происходит фатальный сбой (с потерей
> данных >50%). 2) при прочих равных вероятность восстановления после такого
> сбоя выше?

Я везде использую xfs, исходя из её структуры (экстентная бескластерная, не 
нуждающаяся в дефрагментации и т.п.), и действительно, высокой скорости 
работы с файлами на сильно загруженой машине (множество параллельных файловых 
операций).

Теоретически, структура xfs позволяет надёжно восстановить данные после любого 
сбоя (поскольку возможно сканирование диска с восстановлением структуры). 
Но... Практически, сейчас xfsrecovery *реализована* так, что при попытке 
восстановления ФС с диска с повреждённым или неправильно интерпретируемым 
суперблоком (см. ниже), либо очень тяжёлыми повреждениями, информация 
спасается, но толку с того немного, так как все имена файлов превращаются в 
цифирь.

Правда, я сталкивался с таким казусом только дважды (на более, чем трёх 
десятках машин за эксплуатацию с 2000 г., включая 3 сильно загруженых 
сервера, причём 9 машин - в студенческом уч. классе,  8 -- в школьном, 4  -- 
рабочие места неквалифицированых пользователей, частенько плюющих на 
необходимость нормального завершения работы; 8 - 11 машин работали в полевых 
условиях (правда, статистика здесь поскромнее, всего 3 месяца в общей 
сложности) при постояных перебоях с электропитанием. Две машины, 
обслуживающие некий прибор, были перед новым годом, установлены на газовом 
прииске (проблемы с электропитанием), до сих пор, сообщений о проблемах не 
поступало. Дважды нарывались на серьёзные аппаратные проблемы с винчестерами, 
данные в итоге, не пострадали. 

Обе катастрофы с потерей файловой системы, произошли "на ровном месте", не 
были связаны с  электропитанием и похоже, причина стала понятна:

 В один прекрасный день, система перестала загружаться. Проверка ФС показала  
"потеряный суперблок". xfsrecovery восстановил структуру файловой системы, но 
превратил почти все имена файлов и каталогов в цифирь (тем не менее, 
информация потеряна не была). Списали на проблемы с xfs.

Спустя некоторое время, ситуация повторилась. 

Нечто подобное произошло ещё на одной машине, но там сидел пользователь, 
ничего не знающий о xfs и утилитах восстановления. он просто пожал плечами, 
зашёл в windows (на машине -- и это. по видиму, важно!, стоял винчестер 40G и 
были установлены паралелльно w98, w2000, alt) и запустил штатный виндовый 
fdisk. После чего, и суперблок нашёлся, и проболемы с xfs, сами собой 
исчезли. Важно, что *поверхностный* просмотр таблицы разделов до и после 
"лечения", ничего криминального (вообще никаких изменений), не выявляет.

ситуацию удалось повторить (кстати сказать, что подобные проблемы с 
разрушением файловой структуры, наблюдались и ранее при паралельной установке 
w98 /os/2, но там hpfs и имена файлов всегда восстанавливалсь без проблем).

исходя из этого, рабочая гипотеза:
 w98 *как-то* портит таблицу разделов, или пишет некую служебную информацию 
куда попало.

предварительный вывод (исходя из опыта подобных проблем ранее, с паралельной 
установкой os/2, проблемам с ФС и "жалобами" штатных не-виндовых утилит и 
т.п.): КАТЕГОРИЧЕСКИ НЕЛЬЗЯ ДОПУСКАТЬ W98 К ДИСКАМ ОБЪЁМОМ БОЛЕЕ, ЧЕМ 20G (до 
этого предела. никогда никаких проблем не замечалось).

После удаления w98 с "проблемных" машин, порча ФС более не замечалась.

Единственая острая проблема: "обнуление" открытых на запись файлов при сбое 
электрики, впрочем, в реальных условиях, как правило, страдает только 
конфигурация kde активного пользователя и последний открытый документ, 
катастрофических последствий, никогда не было.

На машинах с единственной установленой ОС, проблем с xfs (несмотря на сбои 
винчестера), не замечалось.

-- 
      Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
netmail: 2:5005/78