Terry Lambert: FreeBSD нужна журналирующая файловая система

1. DARPA вообще много чего финансирует.
2. Да, write barriers реализовано через теги естественно. И я об этом уже писал.
3. Write cache лучше НЕ отключать, потому как write throughput падает весьма заметно. Лучше купить UPS уж тогда. До конца, конечно, не спасет, но вероятность попадалова уменьшит.

2jackill (*):

Я не использую ни 2.5, ни 2.4, ни вообще Linux как таковой. А ссылки я прислал просто с первой страницы mailing lists архивов, как антитезис вашего утверждения о беспроблемности журналируемых FS в Linux. Проблемы есть, случаются в десятки раз чаще, чем с ext2, будем отрицать?

> AIX is dead (*)
Не смешите курей. Вы читали roadmap IBM? Практически все RS/6000 ящики они продают только с AIX, без каких-либо опций. Мне бы не знать, у меня этих машин ~90% в конторе.

> Ни AIX ни Irix вроде бы как на рынок уже серьезно не продвигатся.
Здесь надо уточнять - _вам_ не продвигаются.

> Про BSD нам рассказывать не надо, там до сих пор рейсы в VFS, и это
> при том что такию люди как МакКузик годами вычитывали тот код.
А светоч green про них знает и может указать на них кривым ногтем? Наивно может быть, но почему так не хочется поверить в это сказочку?

При прочих равных, я предпочту довериться коду вычитанному McKuisck-ом, чем продукту творчества Viro. Ну да ладно, Linux у нас race conditions не содержит как класс, мы ж все это знаем. И верим...

Нет. Если б знал - указал бы. Рейсы - штука такая, даже если их можешь воспроизвести - не так то просто поймать.

-- green, который уже почти неделю ловит занудный race.

> - green, который уже почти неделю ловит занудный race.
Что-то подсказывает мне, что не во FreeBSD green этот самый race. А раз так, стоило б ему помолчать. Либо номером PR за своим именем поделиться.

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

--
Неизвестный, который свой race уже поймал :)

Нет, не во FreeBSD, но тем не менее я не вижу почему я должен молчать ;)

> binary upgrade - это, конечно, хорошо, а ты его хоть раз делал?
> Ты не удивлялся, куда некоторые логи деваются? В любом случае, на
> своём опыте я считаю binary upgrade оптимальным в весьма малом
> количестве случаев (например, переход с 3.x на 4.7)

Делал и не удивлялся. В каждой релиз-версии есть INSTALL.TXT и INSTALL.HTM где подробно описано как делать binary upgrade. Подумай
сам, что происходит при binary upgrade? Примерно тоже, что и при
'make installworld', тоесть собственно binary upgrade. Только если
настоящий binary upgrade в качестве источника использует какую-то
installation media (CDROM, FTP, NFS, etc.) с готовыми бинарными
файлами, то 'make installworld' использует /usr/obj для того же.
По сути происходит идентичная операция. Однако в случае
'make installworld' необходимо предварительно сделать ещё несколько
операций, которые займут время и место на диске.

Конечно, идеальных вещей не бывает, но разве ты никогда не читал
письма в freebsd-stable@freebsd.org о том как кто-то сделал cvsup и
всё остальное, а у него что-то не собирается или не работает или
потерялось? Всё таки не зря выходят *.X релизы, согласись.

Санычу: sync на softupdates не действует, по крайней мере сейчас, то есть действует не напрямую. См. ядерные sysctl'и kern.filedelay, kern.dirdelay и kern.metadelay, вот в них таймеры сброса данных. Обычно kern.dirdelay - 29 секунд, то есть 29 секунд от последней записи - сброс всего. Можно поставить в них значения поменьше.

To green@: нафига write cache при работающих тегах? Собственно, на тестах, например, by Soren - при наличии тегов write cache ничего не дает. Без тегов - да. В 4.5 и позже - по дефолту оставлено write cache включенным, просто потому, что это соответствует дефолту без управления этой фичей, и потому, что критичные хранилища на ATA все равно не строят. Но если есть tagged queueing, то write cache идет нафиг.

To anonymous (2003-01-20 18:55:57.142): make installworld НЕ тождественен binary upgrade, не надо иллюзий. Состав файлов при binary upgrade значительно шире, базовый пакет bin содержит еще /etc, /dev после MAKEDEV, файлы в /var, их installworld никогда не ставит. При выборе других пакетов (например, doc) можно получить вещи, которые через installworld не делаются - handbook, faq и прочее. Ну про разные опции сборки я вообще молчу - там простор для деятельности.

Ну а что в stable@ пишут что cvsup сломал что-то - так повторяю: я рекомендую ветки RELENG_x_y при x>=4, которые есть релиз плюс затычки дырок. С них сломать что-то невозможно. RELENG_4 и будущие аналоги - несмотря на слово STABLE в показываемой версии - девелоперские ветки. Binary upgrade штатного типа (через sysinstall) при этом, например, c 4.7-RELEASE на 4.7-RELEASE-p3 - вообще головотяпство со взломом.

> но тем не менее я не вижу почему я должен молчать ;)
В приличном обществе считают принятым молчать о том, о чем не имеешь достаточно глубоких познаний. Ты не имеешь оных о FreeBSD, а посему и не можешь комментировать её проблемы. После "ключевого разработчика и архитектора" Terry сомневаться в этом не приходится.

В приличном обществе непринято скрываться за анонимностью.

> В приличном обществе непринято скрываться за анонимностью.
И это тоже. Однако ж я не постил статью на сайте прикидываясь знающим человеком, и я не строю по своему поводу иллюзий.

А я не прикидываюсь, я действительно так считаю.

Cчитать можешь сколько угодно, осчасливливать _этим_ публику пожалуй не стоит, если не можешь предъявить достаточные credentials. Для FreeBSD ты их предъявить не можешь.

Я встречал Наполеона, но он был тихим, в отличие от...

2MrBool (*) (2003-01-19 13:52:24.214)

> Что же ты это с серваками такое делаешь что они у тебя падают ? :-)

Я сказал _ред-ко_ падают. Работают у меня серваки как папы Карлы. Не везде новые ядра.

> У нас ни один SuSE Linux ниразу не упал, а вот с w2k было дело...

С какого времени? У меня стоят серваки на удаленных площадках по три года ;) Сейчас-то я тоже ставлю ядра от Суси ;)

> make installworld НЕ тождественен binary upgrade, не надо иллюзий.
> Состав файлов при binary upgrade значительно шире, базовый пакет
> bin содержит еще /etc, /dev после MAKEDEV, файлы в /var, их
> installworld никогда не ставит. При выборе других пакетов
> (например, doc) можно получить вещи, которые через installworld не
> делаются - handbook, faq и прочее. Ну про разные опции сборки я
> вообще молчу - там простор для деятельности.

Я не утверждал, что 'make installworld' тождественен binary upgrade.
Состав файлов при binary upgrade действительно шире чем при
'make installworld', ведь эти файлы взаимосвязаны. Зачем оставлять,
например, старую /etc, если она может не работать с новым world?
Естественно стирать /etc не следует, а следует сохранить
переписываемые в ней файлы в каком-то другом месте для последующего
сравнения, что собственно и происходит при binary upgrade. Кроме того,
'make installworld' - далеко не единственая команда, которую тебе
придётся запускать после cvsup. Посмотри, например, `man 8 mergemaster`.

Выбор других элементов base system, например doc - это всё таки выбор,
хотя лично я не вижу ничего плохого в обновлении локальных копий
handbook, faq и другой документации.

> Ну а что в stable@ пишут что cvsup сломал что-то - так повторяю: я
> рекомендую ветки RELENG_x_y при x>=4, которые есть релиз плюс
> затычки дырок. С них сломать что-то невозможно. RELENG_4 и будущие
> аналоги - несмотря на слово STABLE в показываемой версии -
> девелоперские ветки. Binary upgrade штатного типа (через
> sysinstall) при этом, например, c 4.7-RELEASE на 4.7-RELEASE-p3 -
> вообще головотяпство со взломом.

Ну вот заходим по следующему линку:
http://www.freebsd.org/doc/en/books/handbook/cvs-tags.html
и видим, что все RELENG_x_y при x>=4 - "used only for security
advisories and other seriously critical fixes". Все эти, как ты их
назвал, "затычки" доступны не только через cvsup. Вот например,
читаем http://www.freebsd.org/releases/4.7R/errata.html и видим, что
fpathconf(2) имеет проблему. Внимательно читаем описание:
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:44.filedesc.asc

и решаем, а является ли для нас данная проблема критичной?
Если локальных пользователей у тебя нет и система довольно интенсивно
используется (например, как файловый сервер внутри LAN), то возможно,
что ты не станешь спешить прерывать работу своей организации ради
этого. Если же у тебя иная ситуация и исправление проблемы оправдано,
то оптимальнее сделать это так, как написано в секцие Solution того
самого описания. Зачем пересобирать всю систему целиком?

P.S. Возможно, метод обновления системы через CVS популярен чисто по
историческим причинам. Однако мне он кажется не самым оптимальным в
определённых, далеко не редких случаях.

netch@: "...что это соответствует дефолту без управления этой фичей, и потому, что критичные хранилища на ATA все равно не строят..."

А можно чуточку поподробнее? Или хотя бы ссылку(и) на тесты/объяснения? Очень интересует этот вопрос.

Хм... похоже "Auto URL" у этого сайта имеет баг. Green, Maxcom или кто здесь этим занимается? Надо бы исправить.

> Я не утверждал, что 'make installworld' тождественен binary upgrade.
> Состав файлов при binary upgrade действительно шире чем при
> 'make installworld', ведь эти файлы взаимосвязаны. Зачем оставлять,
> например, старую /etc, если она может не работать с новым world?

Для исправления /etc есть mergemaster.
И посмотри как сделано хотя бы в OpenBSD. Как там делятся base, comp,
etc, и прочие. Вот это - базовый разумный подход. Еще бы их в общий
package manager завернуть и тогда все будет точно OK ;)

> Зачем пересобирать всю систему целиком?

А кто сказал про пересборку всей системы целиком? Можно и по частям,
так тоже делаю. Но cvsup'ом догнать сорцы до нужного состояния - это
действительно жизненно важно, это поймешь, когда начнешь путаться в
версиях используемого кода. Еще это пишется в журнал системы, (в смысле
бумажный в столе), но это отдельный вопрос.

> P.S. Возможно, метод обновления системы через CVS популярен чисто по
> историческим причинам. Однако мне он кажется не самым оптимальным в
> определённых, далеко не редких случаях.

Ты не пробовал админить полсотни тазиков с близкими системами?
Попробуй. После чего идея о том, что даже после срочного затыкания
дыры надо сделать cvsup + make world, не покажется тебе странной.



To CruZ: ссылку не дам, слишком общее место, а во многих случаях еще и порочный круг - "раз на ATA ничего нормального не делают, сделаем диски подешевле; раз на ATA диски такие хреновые - не будем на них критичные системы строить". На разрыв такого круга требуются годы и миллионы (кто это будет делать?)

netch@: "...И посмотри как сделано хотя бы в OpenBSD. Как там делятся base, comp, etc, и прочие. Вот это - базовый разумный подход. Еще бы их в общий package manager завернуть и тогда все будет точно OK ;)..."

Ага, pkg_delete base32 будет ввергать админа в состояние нирваны полной нирваны ;))

"...To CruZ: ссылку не дам, слишком общее место..."

Хорошо спрошу по-другому: если можешь поделись своими мыслями по поводу организации этих самых "критических систем". Интересует лично твой опыт и твои наблюдения/рассуждения/выводы по этому поводу и т.д. и т.п. Если хочешь можем продолжить приватно (cruz(at)openbsd(dot)ru).

Просто к слову:

Under Windows XP, NTFS defragments uncompressed files at the cluster boundary. Under Windows 2000, this was done at the page boundary.

взято с

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/...

Это в качестве комментария к статье на IXBT. В XP не происходит появления "дырок" при дефрагментации и, единожды её сделав, нет необходимости постоянно повторять.

У меня стоит дома XP. Вот что показывает анализ диска в стандартном дефрагментаторе (диск был сформатирован при установке XP):

Фрагментация тома Всего фрагментировано = 30 % Фрагментация файлов = 49 % Фрагментация свободного места = 12 %

Так что вроде улучшений с фрагментацией у XP вроде не видно. Сейчас вот сдефрагментирую диск - посмотрим, как будет дальше.

А вообще-то бывают hardware RAID контроллеры с батарейками для того, чтобы можно было сбросить write cache даже если пропало питание. Вот их и надо пользовать для важных машин. Только стоят они недешево.

Ну чего там с дефрагментацией у XP? Сделал кто-нить?

Hi, All! Я смотрю тут все эксперты по journaling filesystems собрались. В системах, где приложения работают на сетевых клиентах и обрабатывают данные в файлах на сервере (пример: DBF-ники), часто происходит следующее: сервер (Win NT, 2000 с NTFS) "падает" по какой-либо причине (неважно по какой), затем админ поднимает сервер, сопровождающий программер восстанавливает базу из резервной копии или ремонтирует руками таблицы (при несложных повреждениях). Далее юзеры продолжают работу (повторяют операции за день - худший случай для клиентов). Через N часов (N не может предсказать даже билли) потерянные записи "восстанавливаются" "умным" сервером с "умной" FS. В результате либо не можем нормально подбить бабки за текущий рабочий день, либо имеем те же проблемы на след. день (таблицы и индексы испорчены). Может кто скажет что умное по этой проблеме? Данного геморроя не возникает, если не используется журн. ФС. Так нах эти журн. ФС нужны? ИМХО по этой же причине некоторые SQL серверы работают с RAW disk space.

Надеюсь услышать компетентное мнение, а не обычные "...во рту росли грибы".

2 Alexander2

ты издеваешься?
журнал восстанавлиевается еще при загрузке машины, пока не восстановлен - FS не монтируется в нормальном режиме и рабоать с ней просто физически невозможно, как же твой гипотетический криворукий админ и программер базу то ручками собираются восстанавливать? :D

2 anonymous (*) (2003-02-05 02:53:43.872): Расскажите-ка нам, любезный, где находится журнал и на основе каких данных он восстанавливается. А еще расскажи нам ВСЕМ про те последствия, которые наступают после разрушения и невозможности восстановить журнал. Неаргументированные мнения не принимаются и их источники отправляются в сад!

ATA -- редкостное г..., как по архитектуре, так и по реализации. Единственный плюс -- дешевое ;-)