Страшные тормоза zfs

Eugene Grosbein написал(а) к Alex Korchmar в Oct 15 15:48:25 по местному времени:

23 окт 2015, пятница, в 15:38 NOVT, Alex Korchmar написал(а):

EG>> Я жил на FAT и с дискетками на машинах PS/2 Model 30 без жестких дисков,
EG>> и на жестких дисках с VFAT и FAT32 и хорошо помню, что это - жизнь на
EG>> вулкане.
AK> чорт, и почему у меня никогда не было проблем с fat, исключая проблемы с
AK> кривым кэширующим софтом?

Не жил на FAT с floppy only-компами, или мало юзал DOS/Windows 3x
(меньше 3 лет), или мало девелопил под ними - откуда мне знать, почему?
У подавляющего большинства народу БЫЛИ проблемы с FAT, отсюда и бешенная
популярность сторонних утилит, начиная с древнего PCTools.

AK> Проблем получить неремонтируемую zfs, что характерно, нет вовсе.
AK> Ну а 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.

Нет, есть существенная разница. Из-за фрагментации в FAT вместо одного
файла в lost+found мы с большой вероятностью получаем несколько его ошметков
в .CНK, причем хвостовые кластеры оригинального файла могут быть
(и часто были) продублированы в нескольких файлах .CНK из-за того,
что в при потере directory entry в FAT невозможно определить, где начало
файла и которому "inode" принадлежит та или иная подцепочка кластеров FAT.
С UFS такого никогда не бывает.

AK> Зато если потерять содержимое inode- с файликом можно попрощаться. А именно
AK> inode обновляется каждый раз, когда надо обновить какой-то вшивый atime.

У FAT всё гораздо печальней, потерять всю FAT легче лёгкого, именно поэтому
к ней позже прикрутили вторую копию FAT, которая в итоге периодически
противоречила первой.

AK> В fat мухи старательно отделены от котлет - абсолютно вся метаинформация лежит
AK> в direntry.
AK> Ну да, ну да - хардлинки невозможны. Много у тебя на диске хардлинков, кроме
AK> технологических . -> .. ? Особенно на портативном.

У меня нет портативных дисков уже давно, а на встроенном хардлинков много.

Eugene
--- slrn/1.0.2 (FreeBSD)

Eugene Grosbein написал(а) к Alex Korchmar в Oct 15 15:52:31 по местному времени:

23 окт 2015, пятница, в 15:56 NOVT, Alex Korchmar написал(а):

EG>> FAT и надежность? Какая-то альтернативная реальность.
AK> 2:5020/28.100 все еще стоит в соседней комнате. Ей двадцать лет. Она, думаю,
AK> все еще включается, ну может батарейку придется перепаивать. Диски
AK> не менялись с момента сборки. Кэшируются - не помню, чем. Что я
AK> делал не так?
AK> /28, если что, тоже fat. И многозадачная система поверх. Собственно,
AK> полнофункциональный фидошный узел - одна из сложнейших систем,
AK> когда-либо построенных на базе dos. Проработала уже в моих руках с
AK> 92го по 99й. Заменялось все, кроме как раз дисков. Там, правда,
AK> уже был ups, и большая часть жизни была на сетевых дисках. Впрочем,
AK> это netware 3.11, опять же fat.

В тепличных условиях (UPS, отсутствие нестабильного софта)
любая вменяемая fs будет нормально работать. Речь не про тепличные условия.

AK> так что это у тебя какая-то альтернативная реальность. Грохнувшихся, полностью
AK> похоронив под собой информацию, hpfs, ext2, ext3, xfs, ufs в разных позах я
AK> за эти годы повидал множество.
AK> reizer удалось починить, не заплатив $20, до сих пор должен их Олегу.

Мне только один раз не удалось полностью починить UFS -
когда запустил newfs -O2 по отмонтированному /usr/local вместо нового диска.
Во всех остальных случаях проблем не было.

Eugene
--- slrn/1.0.2 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в Oct 15 15:01:06 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> чорт, и почему у меня никогда не было проблем с fat, исключая проблемы с
AK>> кривым кэширующим софтом?
EG> Не жил на FAT с floppy only-компами, или мало юзал DOS/Windows 3x
кому ты рассказываешь эти сказочки?
Как насчет чудесного компьютера "нейрон" с чудесным драйвером 720k?
Ну да, не надо, наверное, рвать дискету из привода, пока горит лампочка,
или хотя бы в ответ на "abort/retry" обратно ее засунуть (работало еще в
98й, современные мега-системы конечно же намертво разучились повторно
записывать незаписавшееся, если устройство вернули обратно, это ж так сложно
реализовать, вот panic() - это по нашему)

EG> У подавляющего большинства народу БЫЛИ проблемы с FAT, отсюда и бешенная
подавляющее большинство народу - тупые дибилы. У них со всем проблемы.

EG> популярность сторонних утилит, начиная с древнего PCTools.
ни разу не видел никого, кто сперва умудрился бы испортить диск, а потом
чинил бы его pctools. А, нет, оно, кажется, умело искать бэдсекторы
- а это тогда была проблема. Но фат в ней совершенно не виноват, он,
в отличие от новых-модных, неплохо умел с ними жить, не надеясь на
ремап.

Обычно и его, и более современный diskedit использовали совсем не для благих
целей. И я в том числе.
Кстати, во времена fat32, внезапно, интерес к подобным утилитам пропал начисто
- я лет пять или даже больше назад, когда еще теплилась жизнь в ru.linux,
пытался что-то найти, в том числе путем опроса публики - и был поражен,
что, оказывается, остались только какие-то совсем ушлепские поделки
студентов-первокурсников.
Мне надо было fat16, на самом деле, и проще всего оказалось соорудить себе
среду, где, с грехом пополам, запустился доисторический de и драйвер
моего носителя. А с fat32 пришлось бы все делать руками через dd
и ручной поиск смещений, вот было б щастье.

Наверное, пропавшая надобность в этих инструментах, это от того, что fat32
не портится, да?
Точно-точно не от того, что для копирования dvd со starforce подобные утилиты
мала-мала перестали бы полезны вовсе, да и dmca их не одобряет?

AK>> Проблем получить неремонтируемую zfs, что характерно, нет вовсе.
AK>> Ну а ufs, если что, отремонтируется быстро,
EG> У меня были проблемы с UFS из-за плохого блока питания, в результате чего
EG> был убит суперблок, и ничего - fsck с резервным суперблоком отработал,
повезло, а у меня была масса походов к стойкам, где уже ничего бы не помогло.
Отчасти из-за background fsck новомодного, но чаще из-за default sync mount.
Ну и грабли с то работающими, то гробящими диски софтапдейтами.

AK>> правда своих файлов ты на ней уже не увидишь.
EG> Вовсе не обязательно.
и с fat необязательно. То есть я вот вообще не помню за собой потери файлов
на fat, если они, конечно, не писались прямо в момент ресета - но тогда
терялось то что писалось, а не все к хренам. На hpfs - бывало, при том что
она даже кэшироваться не умела. На ext2-3-4 - по всей роже (особенно
удался журнал ext3 без барьеров и без контроля целостности).
xfs просто "сервер повис, причина стандартная, в reinstall",
reizer - запуск fsck не с дефолтными параметрами приводил к выводу
таблички "заплати нам $20, мы тебе все починим" (не врали, но я больше одного
раза не пробовал)
про zfs, к счастью, только читаю ужасы. C ntfs опыт
сильно ограничен, но тоже ни одной серьезной проблемы.

Это при том что коллега за соседним столом отлаживал на 95й винде складской
учет. clarion for dos4g, слышал о таком? То есть приличное число тестовых
запусков заканчивалось кнопкой reset. Равно как и внезапное открывание двери
при запущенных heroes1 вместо клэриона - к сожалению, винда почему-то не могла
восстановить графику после выхода из его fullscreen.
И что-то вот не помню я за ним панического рванья волосьев на жопе (кроме
почти выигранной битвы в героях, прерванной таким способом) -
ну тоже, иногда приходилось доставать из бэкапа тот файл, который в этот
момент был открыт в редакторе. А массовых разрушений за пару-тройку лет не
наблюдалось ни разу.
Повезло? Безусловно, могло и разворотить - но вот я за это время пару раз
таки переставлял модные тогда у фидошников операционные системы, хотя
обращался с ними гораздо гуманнее - у меня переключение из героев графику
не роняло.

EG> Нет, есть существенная разница. Из-за фрагментации в FAT вместо одного
EG> файла в lost+found мы с большой вероятностью получаем несколько его
при больших повреждениях нам это глубоко похрен - все равно нет возможности
разобрать помойку, где в lost лежит пара сотен непоймичего, пусть даже и
по одному куску на файл.
Рецепт тот же что и с fat - удаляем все нахрен и надеемся, что это не был
какой-нибудь особо нужный для жизни файл.

EG> С UFS такого никогда не бывает.
ну да, зато повреждения inode бывают. Заметь, ни dos, ни винда туда без
острой необходимости не лезут, atime update хитрокэшируется (но не теряется
вовсе, как у линуксов с relatime), а больше там делать нечего.

EG> У FAT всё гораздо печальней, потерять всю FAT легче лёгкого, именно поэтому
для этого надо прицельно записать мусор, причем не в один, а во все
сектора. Да, возможно - при полностью сошедшей с ума операционке,
но fat тут не виновата.

EG> к ней позже прикрутили вторую копию FAT, которая в итоге периодически
позже, это, прости, в 84м году? Впрочем, википедия врет нам, что,
наоборот, в 80-м, когда никакого msdos еще не существовало, reduced
the number of FATs to two, видимо, диски стали более надежны, и надобность
в третьей копии отпала.
Ни одна из стандартных версий format ни на каких носителях, включая single
side single dencity, никогда не производила ублюдков с единственной fat.
Может, твои детские травмы связаны с использованием какого-то сильно
левого софта, пытавшегося выгадать таким образом еще
килобайтик? Оно даже, наверное, читалось-писалось бы потом.

EG> У меня нет портативных дисков уже давно
и эти люди будут учить меня правильно ковыряться в носу?


> Alex

--- ifmail v.2.15dev5.4

Alex Korchmar написал(а) к Eugene Grosbein в Oct 15 16:36:10 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> /28, если что, тоже fat. И многозадачная система поверх. Собственно,
AK>> полнофункциональный фидошный узел - одна из сложнейших систем,
AK>> когда-либо построенных на базе dos. Проработала уже в моих руках с
AK>> 92го по 99й. Заменялось все, кроме как раз дисков. Там, правда,
AK>> уже был ups, и большая часть жизни была на сетевых дисках. Впрочем,
AK>> это netware 3.11, опять же fat.
EG> В тепличных условиях (UPS, отсутствие нестабильного софта)
фидошная нода как она выглядела в те годы - это "тепличные условия" и
"отсутствие нестабильного софта"? Я точно не в дурдом попал?

И да, для пациентов последний раз повторяю: навернувшихся в стойке в датацентре
от неведомых причин я видел все ваши любимые опенсорс поделки.
С упсами (которые иногда, внезапно, тоже выключаются), кондиционированием,
и самым стабильным в мире софтом имени косоруких опенсорсных обезьянок.
При том что современные софт и железо хотя бы защиту памяти худо-бедно
обеспечивают.

EG> Мне только один раз не удалось полностью починить UFS -
потерять половину содержимого или принять его в lost+found в виде, бесполезном
для любого практического употребления - это не "починить".


> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Oct 15 16:00:14 по местному времени:

26 окт 2015, понедельник, в 16:01 NOVT, Alex Korchmar написал(а):

AK>>> чорт, и почему у меня никогда не было проблем с fat, исключая проблемы с
AK>>> кривым кэширующим софтом?
EG>> Не жил на FAT с floppy only-компами, или мало юзал DOS/Windows 3x
AK> кому ты рассказываешь эти сказочки?
AK> Как насчет чудесного компьютера "нейрон" с чудесным драйвером 720k?
AK> Ну да, не надо, наверное, рвать дискету из привода, пока горит лампочка,

А аварийный ребут компа при горящей лампочке, разносящий FAT в состояние,
требующее сторонних утилит для восстановления?

EG>> У подавляющего большинства народу БЫЛИ проблемы с FAT, отсюда и бешенная
AK> подавляющее большинство народу - тупые дибилы. У них со всем проблемы.

FAT ни разу не дуракоустойчива, так что инженерный гений - не про неё.

EG>> популярность сторонних утилит, начиная с древнего PCTools.
AK> ни разу не видел никого, кто сперва умудрился бы испортить диск, а потом
AK> чинил бы его pctools.

Утилит - множественное число. PCTools просто был уже малопопулярен к тому
времени, когда у нас распространился ворованный (иногда даже предустановленный)
DOS, ворованные утилиты Нортона были популярнее. Вроде были и другие,
названия уже не помню.

AK> Кстати, во времена fat32, внезапно, интерес к подобным утилитам пропал начисто
AK> - я лет пять или даже больше назад, когда еще теплилась жизнь в ru.linux,
AK> пытался что-то найти, в том числе путем опроса публики - и был поражен,
AK> что, оказывается, остались только какие-то совсем ушлепские поделки
AK> студентов-первокурсников.

FAT32 появился только с OSR2. К тем временам MS давно заменила тупейший
CНKDSK на более вменяемый ScanDisk для DOS и прикрутила гуёвый к Win95,
что и уменьшило интерес к сторонним утилитам, хотя Нортон ещё трепыхался.

AK> Наверное, пропавшая надобность в этих инструментах, это от того, что fat32
AK> не портится, да?

Нет, оно тоже портилось, но, во-первых, чинилось уже штатными утилитами,
в отличие от штатного CНKDSK для FAT16, а во-вторых, появилась ядро
понадежнее и сами случаи, когда требуется починка FS, стали на порядок реже.
Но инженерного гения в FAT от этого не добавилось.

AK> Это при том что коллега за соседним столом отлаживал на 95й винде складской
AK> учет. clarion for dos4g, слышал о таком? То есть приличное число тестовых
AK> запусков заканчивалось кнопкой reset.

И я уверен, что у такого коллеги соломка была подстелена везде,
где только можно - но это опять же не признак инженерного гения в FAT.

EG>> С UFS такого никогда не бывает.
AK> ну да, зато повреждения inode бывают. Заметь, ни dos, ни винда туда без
AK> острой необходимости не лезут, atime update хитрокэшируется (но не теряется
AK> вовсе, как у линуксов с relatime), а больше там делать нечего.

atime update везде кешируется.

For ufs, the atime update is done using delayed writes (c) bde@ 2002

EG>> У FAT всё гораздо печальней, потерять всю FAT легче лёгкого, именно поэтому
AK> для этого надо прицельно записать мусор, причем не в один, а во все
AK> сектора.

Как раз достаточно успеть записать только один (первый) и необязательно
мусор - просто недописать новое положение дел.

AK> Да, возможно - при полностью сошедшей с ума операционке,
AK> но fat тут не виновата.

Ещё как виновата, при её структуре иначе никак - атомарности никакой.

EG>> к ней позже прикрутили вторую копию FAT, которая в итоге периодически
AK> позже, это, прости, в 84м году? Впрочем, википедия врет нам, что,
AK> наоборот, в 80-м, когда никакого msdos еще не существовало, reduced
AK> the number of FATs to two, видимо, диски стали более надежны, и надобность
AK> в третьей копии отпала.

Да, я это с прямым углом спутал. Но две копии FAT всё таки прекрасное
инженерное решение - когда они начинают противоречить друг другу,
нет контрольной копии.

Eugene
--- slrn/1.0.2 (FreeBSD)

Eugene Grosbein написал(а) к Alex Korchmar в Oct 15 16:05:17 по местному времени:

26 окт 2015, понедельник, в 17:36 NOVT, Alex Korchmar написал(а):

AK>>> /28, если что, тоже fat. И многозадачная система поверх. Собственно,
AK>>> полнофункциональный фидошный узел - одна из сложнейших систем,
AK>>> когда-либо построенных на базе dos. Проработала уже в моих руках с
AK>>> 92го по 99й. Заменялось все, кроме как раз дисков. Там, правда,
AK>>> уже был ups, и большая часть жизни была на сетевых дисках. Впрочем,
AK>>> это netware 3.11, опять же fat.
EG>> В тепличных условиях (UPS, отсутствие нестабильного софта)
AK> фидошная нода как она выглядела в те годы - это "тепличные условия" и
AK> "отсутствие нестабильного софта"? Я точно не в дурдом попал?

Фидошная нода была вся обложена не просто соломкой, а толстенными
соломенными матрацами.

AK> И да, для пациентов последний раз повторяю: навернувшихся в стойке в датацентре
AK> от неведомых причин я видел все ваши любимые опенсорс поделки.

Да причем тут опенсорс, мы про FAT crash consistency говорим.

EG>> Мне только один раз не удалось полностью починить UFS -
AK> потерять половину содержимого или принять его в lost+found в виде, бесполезном
AK> для любого практического употребления - это не "починить".

Потерять половину содержимого в UFS - такого не было.
Отказ копаться в lost+found это личный выбор, я доставал оттуда файлы -
чинил официальное зеркало библиотеки Мошкова после креша ядра.

Eugene
--- slrn/1.0.2 (FreeBSD)

Victor Sudakov написал(а) к Dmitry Miloserdov в Oct 15 22:00:12 по местному времени:

Dear Dmitry,

26 Oct 15 19:54, you wrote to me:
>> Из их писаний я сделал вывод, что если синхронных операций (например
>> СУБД) на диск не ведется, то log вообще никак не используется. На
>> диске с фильмами можно поставить sync=disabled и не париться про
>> лог.
DM> Синхронные операции это не только СУБД.
DM> Это может быть любая запись после которой файл был закрыт.

Я так понял, что синхронные операции - это когда fsync() вызывают или открывают файл с O_SYNC.

DM> Возможно для файлопомойки некритично, но может случиться
DM> так что ты фильм скачал и даже посмотрел а на диске его нет.

Как это?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20110223-b20110223