EG>> Я жил на FAT и с дискетками на машинах PS/2 Model 30 без жестких дисков, EG>> и на жестких дисках с VFAT и FAT32 и хорошо помню, что это - жизнь на EG>> вулкане. AK> чорт, и почему у меня никогда не было проблем с fat, исключая проблемы с AK> кривым кэширующим софтом?
Hе жил на FAT с floppy only-компами, или мало юзал DOS/Windows 3x (меньше 3 лет), или мало девелопил под ними - откуда мне знать, почему? У подавляющего большинства народу БЫЛИ проблемы с FAT, отсюда и бешенная популярность сторонних утилит, начиная с древнего PCTools.
AK> Проблем получить неремонтируемую zfs, что характерно, нет вовсе. AK> Hу а ufs, если что, отремонтируется быстро, У меня были проблемы с UFS из-за плохого блока питания, в результате чего был убит суперблок, и ничего - fsck с резервным суперблоком отработал, как ожидалось и сервер поднялся и работал дальше.
AK> правда своих файлов ты на ней уже не увидишь.
Вовсе не обязательно.
EG>> многочисленные сторонние утилиты, которые делали жизнь с FAT сносной, EG>> начиная с NDD и заканчивая резидентными утилитами, которые периодически AK> я никогда в жизни не пользовался ndd, зато пару раз пользовался diskedit для AK> починки последствий запуска глупым юзером ndd. Мы его именовали norton AK> disk destroyer, если что. Что я делал не так?
Погоняло norton disk destroyer появилось, во-первых, во временя ndd 3.x или 4.x, а во-вторых, из-за того, что он позволял глупому юзеру прострелить себе ногу, даже не понимая этого. Ndd 6.x/7.x был уже вполне юзабельным, но хотя ложечки нашлись, осадочек остался. А зря.
AK> Имя файла в fat хранится _в_очнейшем_ подобии ufs - в directory entry. AK> Если его потерять, то, сюрприз, сюрприз - получим ровно то же самое - AK> файлик с дурацким именем в lost+found.
Hет, есть существенная разница. Из-за фрагментации в FAT вместо одного файла в lost+found мы с большой вероятностью получаем несколько его ошметков в .CHK, причем хвостовые кластеры оригинального файла могут быть (и часто были) продублированы в нескольких файлах .CHK из-за того, что в при потере directory entry в FAT невозможно определить, где начало файла и которому "inode" принадлежит та или иная подцепочка кластеров FAT. С UFS такого никогда не бывает.
AK> Зато если потерять содержимое inode- с файликом можно попрощаться. А именно AK> inode обновляется каждый раз, когда надо обновить какой-то вшивый atime.
У FAT всё гораздо печальней, потерять всю FAT легче лёгкого, именно поэтому к ней позже прикрутили вторую копию FAT, которая в итоге периодически противоречила первой.
AK> В fat мухи старательно отделены от котлет - абсолютно вся метаинформация лежит AK> в direntry. AK> Hу да, ну да - хардлинки невозможны. Много у тебя на диске хардлинков, кроме AK> технологических . -> .. ? Особенно на портативном.
У меня нет портативных дисков уже давно, а на встроенном хардлинков много.
