LINUX.ORG.RU

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


0

0

В своем сегодняшнем письме в список рассылки freebsd-fs Terry Lambert заявил, что в современном мире технология SoftUpdates не подходит для защиты целостности файловой системы при пропаданиях питания или "перезагрузках FreeBSD в случае программных сбоев". "Те кто утверждают что softupdates являются полноценной заменой журналирующей файловой системе - должны перестать распространять неправду". В письме приводятся аргументы в пользу журналирующих файловых систем перед SoftUpdates при пропаданиях питания и другие любопытные размышления и факты.

Заканчивается письмо одобрением создания журналирующей файловой системы для FreeBSD (под BSD лицензией).

>>> Оригинальное письмо на английском.

★★★★★

Ответ на: комментарий от green

> один из ключевых FreeBSD архитекторов

Ну где, ну где ты это взял? Какой архитектор, какой ключевой, где растёт такая трава?

anonymous
()
Ответ на: комментарий от anonymous

Тут какой-то мисандерстендинг. Наэтм треке живет журнальная инфа. Если коммитить треками, то если какой-то трек не читается- то считаем что его и не записывали. Соответственно его и все что дальше проигрывать не пытаемся. Таким образом консистентность fs сохраняется за счет предыдущих транзакций.

green ★★★★★
() автор топика
Ответ на: комментарий от green

> Почему *BSD ядра не используют этот подход я незнаю.

Кто сказал, что не используют? Саныч? И его на свой сайтик приобщи, можешь даже обозвать его самым крутым BSD хакером в веках. Ему понравится.

anonymous
()
Ответ на: комментарий от anonymous

Незнаю зачем делают -RELEASE. Многие мои знакомые используют искоючительно cvsup + make buildworld и тп.

green ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Только что был выдан линк на "disk tuning" где написано, что write chache нужно отключить. А вообще был задан вопрос "почему не используют", какой вопрос такой ответ ;)

green ★★★★★
() автор топика
Ответ на: комментарий от green

> Ну что ж, вырвите высказывание действоительно ключевой, по вашему
> мнению, фигуры на эту тему и опубликуйте его здесь.

А оно вроде бы известно всем, мало мальски знакомым с предметом.
Никто не сможет обвинить меня в том, что Marshall McKusick - это действительно ключевая для всех BSD систем фигура, я надеюсь?
http://www.usenix.org/publications/library/proceedings/usenix2000/general/sel...

Со своей стороны я считаю, что softupdates не являются полноценной заменой журнала, но имеют и свои сильные стороны, которых у журнала нет.

anonymous
()
Ответ на: комментарий от anonymous

Эта статья датирована 2000м годом. Он не передумал еще? Прогресс то на месте не стоит. То что у каждого подхода есть свои сильные стороны я и не спорю. Кстати уже появляются гибридные подходы. (а может и давно существуют, надо бы поподробнее про XFS будет почитать как-нибудь).

green ★★★★★
() автор топика
Ответ на: комментарий от Irsi

Да вроде NTFS не 10 лет назад вылупилась.... в NT 3.51 ее как бы не было? а NT 4 в 1996 году выпустили.

german
()

Хочу сказать!
Именно про недостаток, нет не софтапдейтсов а системы управления проектом ФрииБСД. Вот решили девелоперы (неверно несколько человек согласилось, а решал вообще один) что журнал отстой бум софтапдейтс мутить и все застряла файловая система в бсд на несколько лет. За это время в линуксе появилось несколько разнообразных журналируемых ФС, потому что в линуксе нет догмата, как в бсд, где если дядя сказал мол журнал отстой значит фффсе и точка.

anonymous
()

Зелёный, тебя здесь ещё не замучали? Запостил новость на свою голову... =)

xlex
()

> Эта статья датирована 2000м годом. Он не передумал еще?
А он написал новый paper? Нет? Значит не передумал.

> Только что был выдан линк на "disk tuning" где написано, что write
> chache нужно отключить.
Надо. Только там ещё про tags не писали? Которых выключать как бы не советовали. А тупое hardware write cache вообще надо выкинуть, особенно для IDE дисков, которые в массе своей _лгут_ при команде на сброс кэша и ничего никуда не сбрасывают. Разработчики XFS вам скажут то же самое.

anonymous
()

4Irsi: Сейчас там 6.9Gb занято и 2.8 свободно. Но это после чистки,
а так месяца два вообще 300 метров было свободно.

Вопрос в воздух: если журналируемые фс такое г, то чего же их
такое количество?

4кто-то на ext2: потеряешь хотя бы четверть данных - перестанешь
жалеть скорость. К тому же большое количество памяти очень
помогает.

P.S. А чем ext3, xfs, reserfs или jfs плохи как журналируемые системы?
Что значит "недоделаные"?

jackill ★★★★★
()
Ответ на: комментарий от green

> Незнаю зачем делают -RELEASE. Многие мои знакомые используют
> искоючительно cvsup + make buildworld и тп.

А зачем они это делают? Они принимают участие в разработке или им
интересно следить за этим процессом? Если нет, то мне непонятны
причины использования cvsup + make buildworld, тем более если они это
делают на рабочей машине.
Для обновления рабочей системы существует sysinstall(8) умеющий
делать binary upgrade. Для устранения найденых в релиз-версии проблем,
до выхода следующей релиз-версии, используйте патчи, линки на которые
всегда можно найти прочитав Errata или подписавшись на
freebsd-announce@freebsd.org

Может многие ваши знакомые не читали FreeBSD Handbook?

anonymous
()
Ответ на: комментарий от jackill

> А чем ext3, xfs, reserfs или jfs плохи как журналируемые системы?
> Что значит "недоделаные"?
Вот пройдёт неделя, когда никто не пожалуется на необъяснимую потерю данных в соответствующих листах, тогда можно будет делать заключение о их доделанности.

anonymous
()
Ответ на: комментарий от jackill


> 4кто-то на ext2: потеряешь хотя бы четверть данных - перестанешь жалеть скорость.

Ты наверное пошутил. Потерять данные на ext3 гораздо проще.
За то время, что я ее испытывал было найдено 3 серьезных бага.
В ext2 - ноль. Не представляю, что нужно сделать, чтобы
потерять четверть данных... По-умолчанию fsync вызывается
каждые 30 сек. Дисков, объемом меньше 10Гиг сейчас трудно.
А скорость их записи измеряется пока только в десятках мегабайт в секунду.

anonymous
()
Ответ на: комментарий от Irsi


>XFS просьба не вспоминать - то что живет под линуксом, от оригинала >отличается радикально.

С этого места поподробнее, г-н Ирси.

anonymous
()
Ответ на: комментарий от anonymous

Как я уже сказал (или еще нет?) я незнаю зачем они это делают, но они утверждают что это круто и что таким макаром они собирают всю систему под себя так как им нужно. А не так как нужно непонятно кому.

green ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Будьте добры ссылочку не более чем месячной давности на письмо о необъяснимых потерях данных в ext3/reiserfs в кернелах 2.4.19+

green ★★★★★
() автор топика

Сейчас найдется куча доброжелателей, которые захотят срочно
рассказать тебе про jornal режим в ext3 (причем данные терялись
при шатдауне, насколько я помню).
Больше багов что-то не припоминаю.

jackill ★★★★★
()
Ответ на: комментарий от green

> Как я уже сказал (или еще нет?)

Нет, ещё не говорил.

> я незнаю зачем они это делают, но они утверждают что это круто и
> что таким макаром они собирают всю систему под себя так как им
> нужно. А не так как нужно непонятно кому.

Так всё таки, так как нужно им или так как нужно непонятно кому в CVS
репозитории? Если вариант новер раз, то было бы интересно узнать, что
именно и где они меняют? Если вариант номер два, то мы возвращаемся
к моему предыдущему постингу.

anonymous
()

Хотел спросить и экспертов по БЗДе - а от чего та самая группа называется 'wheel'?

anonymous
()
Ответ на: комментарий от anonymous

Так как нужно им (note "А не" в следующем предложении). Меняют в основном флаги gcc. В make.conf наверное.

green ★★★★★
() автор топика
Ответ на: комментарий от anonymous

to anonymous (*) (2003-01-18 21:52:38.256) :

>А я отказался от ext3. Если честно, то меня задавила жаба. Не смог
>спокойно перенести 15-20% потери производительности файловой системы ;)
>Серваки падают очень редко. 10 минут fsck пережить можно.

Что же ты это с серваками такое делаешь что они у тебя падают ? :-)
У нас ни один SuSE Linux ниразу не упал, а вот с w2k было дело...

MrBool
()

А когда в замечательной NTFS появились квоты и нормально заработали? Или то все-таки была проблема NT4, а не NTFS?

anonymous
()

Кстати любопытный вопрос, квоты на NTFS все так же не считают те маленькие файлы которые хранятся в MFT? А MFT все так же не может быть уменьшена в размерах по мере удаления из нее данных?

green ★★★★★
() автор топика

>> XFS просьба не вспоминать - то что живет под линуксом, от оригинала отличается радикально.

а ну ка расскажи нам поподробнее про "радикально" ???

и еше, мужики, заканчиваете рисовать очередных коней в вакууме.
Блин, финансовая транзакция в ХХХ тыс. $ на писюке с проблемой в питании на IDE харде...

Да и к тому же нормальным базам файловая система вообще побоку...
raw device..


ifconfig
()
Ответ на: комментарий от ifconfig

Возможно ты не поверишь, но у SCSI дисков тоже бывает кеш. К тому же большой.

green ★★★★★
() автор топика
Ответ на: комментарий от anonymous

> С этого места поподробнее, г-н Ирси.

Отвечу я, можно? Итак, отличия:

1. Полностью вынесена за рамки FS система buffer cachе. Вместо неё введена неполноценная система pagebuf. Почему неполноценная, спросите вы? Потому как является частью в себе, не имеет обратной связи с другими частями системы, и соответственно с трудом адаптируется к текущим load, paging условиям.

2. В силу разности реализаций disk io, в частности в том, какая часть кода выполняется в interrupt context, а какая нет, и в том, что позволено interrupt handler-ам в плане синхронизации, XFS на Linux вынужден использовать spinlock_t в нескольких местах, где Irix использует sleep mutex. Результат - несколько неприятных ситуаций, где один user-land процесс может уморить голодом других. Ситуация редкая, но не невозможная.

3. Всё вышеописанное, только из-за маленьких неконсистентностей в реализации примитивов синхронизации.

4. Гарантированная неподержка XFS под Linux GRIO (guaranteed rate io).

:0

anonymous
()
Ответ на: комментарий от jackill

Доброжелателя звали?

EXT3:
NULL pointer dereference:
https://listman.redhat.com/pipermail/ext3-users/2003-January/004585.html

ext3 instability in RH8.0?
https://listman.redhat.com/pipermail/ext3-users/2003-January/004586.html

[patch 2.4] Fix ext3 scheduling storm and lockup
https://listman.redhat.com/pipermail/ext3-users/2003-January/004644.html

2.4.21-pre3 - problems with ext3
https://listman.redhat.com/pipermail/ext3-users/2003-January/004620.html
Продолжать?

XFS:
Просто subject lines, я на список подписан:

From: Neil Conway <neilc@samurai.com>
To: linux-xfs@oss.sgi.com
Subject: 2.5.56: dinode corruption
Date: 13 Jan 2003 21:57:30 -0500
Sender: linux-xfs-bounce@oss.sgi.com

From: Mario Joussen <mario@joussen.org>
To: linux-xfs@oss.sgi.com
Subject: Kernel 2.4.18 + xfs 1.1 + xfsdump = kernel oops
Date: Mon, 13 Jan 2003 10:24:59 +0100
Sender: linux-xfs-bounce@oss.sgi.com

Сильно не искал даже.

C чем прощаюсь.

Доброжелатель.

anonymous
()
Ответ на: комментарий от anonymous

К сожалению все сообщения не в тему. Я специально подчеркнул - запрос был про _ПОТЕРЮ ДАННЫХ_, ни в одном из писем по ссылкам ничего такого нет. Да, есть зависания/нестабильность у ext3 (гм почему только ext3? это теперь такой модный мальчик для битья?)

XFS не считается, потому как в условиях задачи его не стояло.

green ★★★★★
() автор топика
Ответ на: комментарий от green

> специально подчеркнул - запрос был про _ПОТЕРЮ ДАННЫХ_,
Спасибо, следующий раз при аварийной загрузке сервера я буду с благодарностью вспоминать о том, что данные, оказывается, не потерялись. И буду свято верить что так оно будет и впредь, oops там или не ооps.

При чём здесь твой запрос, green? Вопрос, на который действительно имело смысл ответить, звучал так: Почему ext3, XFS и reiser - это пока недоделки? Ответ был - вот поэтому.... :)

anonymous
()
Ответ на: комментарий от anonymous

В таком случае какие "доделки" (или какое подходящее слово нам предложат любители русской словесности?) вы можете предложить нашему вниманию?

green ★★★★★
() автор топика
Ответ на: комментарий от anonymous

> Хотел спросить и экспертов по БЗДе - а от чего та самая группа
> называется 'wheel'?

Возможно мой ответ будет неточным, я не считаю себя большим экспертом,
но могу предложить зайти по следующему линку и посмотреть два
последних пункта перевода:

http://lingvo.yandex.ru/cgi-bin/lingvo.pl?lw=1&CardId=Sd2hlZWw=;L0F

anonymous
()

С моей точки зрения интересная новость состоит в том что один из ключевых FreeBSD архитекторов высказал идею о необходимости журналирующей FS для FreeBSD и чем скорее тем лучше. А что там ты в своей паранойе выдумал - это уже конечно твое дело.

Тери никогда ничего в проекте не решал. Его мнение всегда оценивалось как мнение клоуна. Ты насколько часто читаешь фрёвые листы? Полистай их за года 3-4 и ты узнаешь кто такой Тери

anonymous
()
Ответ на: комментарий от green

> В таком случае какие "доделки" вы можете предложить нашему вниманию?

Вам радикально, или по мелочи?

Если по-мелочи, то вниманию уважаемой публики предлагаются UFS на BSD и Ext2 на Linux. И та, и другая замечательно стабильны.

Если почему-то список выше не устраивает, то публике стоит серьёзно обратить внимание на AIX c JFS, Irix c XFS, Solaris с Veritas (here be dragons). Это радикальное предложение.

Всё, за исключением последней, отличаются завидной стабильностью, не чета Linux. Последняя, хотя и страшновата временами, но всё-же даст сто очков "недоделкам".

anonymous
()
Ответ на: комментарий от green

> Так как нужно им (note "А не" в следующем предложении).
> Меняют в основном флаги gcc. В make.conf наверное.

Да, иногда такой метод оптимизации оправдан. Но я всё же не понимаю,
зачем они делают cvsup? Они априори считают, что все изменения в CVS
репозитории правильные и им нужные? Насколько я знаю, CVS
предназначен, не столько пользователам, сколько разработчикам.
А из твоих слов я понял, что твои знакомые к разработке FreeBSD имеют
очень слабое отношение.
Про переход от одной релиз-версии к другой релиз-версии я уже говорил,
видимо твои знакомые используют -STABLE, да? Зачем им это нужно, да
ещё на рабочей машине? Они читали FreeBSD Handbook или всё таки нет?

anonymous
()
Ответ на: комментарий от anonymous

> Тери никогда ничего в проекте не решал. Его мнение всегда
> оценивалось как мнение клоуна. Ты насколько часто читаешь фрёвые
> листы? Полистай их за года 3-4 и ты узнаешь кто такой Тери

К сожалению Green не читает сообщения FreeBSD mailing lists регулярно.
У него есть какие-то надёжные источники, которые иногда присылают ему
какие-то обрывки от туда. Видимо нам нужно дождаться когда кто-то из
тех надёжных источников тут объявится.
А к Green-у приставать не надо, он Linux Hacker и загружен другой
работой.

P.S. Green, не обижайся, ты иногда делаешь полезные вещи :-))

anonymous
()

4Доброжелатель. Ок.
1-я ссылка:
I tried to use cdrdao on 2.5.5x kernels but kernel gives me following
messages. Further debugging reveals that sb is NULL in __ext3_std_error()
function. I tried this on ext2 and it seems it isn't ext3 specific, on
ext2 it also doesn't work.

Ты используешь ядра 2.5.5х? На серверах? Поздравляю.

2-я ссылка:
ядро 2.4.18-14 в rh 8.0 (нестабильный дистрибутив)

3-я ссылка:
This patch fixes an inefficiency and potential system lockup in the 2.4...

4-я ссылка: не сиди на девелах, говорили же...



jackill ★★★★★
()
Ответ на: комментарий от anonymous

Irix is dead. (*) AIX is dead (*)

Про BSD нам рассказывать не надо, там до сих пор рейсы в VFS, и это при том что такию люди как МакКузик годами вычитывали тот код.

А у ext2 на Linux тоже есьт свои проблемы.

(*) - Обе компании теперь занимаются Linux в основном. Ни AIX ни Irix вроде бы как на рынок уже серьезно не продвигатся. К тому же Irix требует себе экзотические CPU.

green ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Я незнаю зачем они это делают, но по моим наблюдениям практически все админы *BSD периодически делают cvsup. Наверное это потому что эо лучший из доступных им методов для обновления системы.

green ★★★★★
() автор топика
Ответ на: комментарий от jackill

На самом деле RH 8.0 весьма стабильный дистрибутив. По крайней мере не хуже чем RH 7.3 (кое в чем пожалуй и получше)

green ★★★★★
() автор топика

Хотел бы напомнить, что в FreeBSD была журнальная файловая система LFS, и я ее даже пробовал как-то раз. Там были баги. Их никто не правил, видно, никому из разработчиков это не было нужно. Потом в какой-то момент после очередных исправлений в VFS, соответствующие правки в LFS внесены не были, и она вообще компилироваться в ядро перестала. А еще через пару лет ее вообще из ядра выкинули.
Кстати, в LFS в журнал писалось все, и данные в том числе.

lukin
()

2german: NTFS (NT File System) появилась вместе с первой версией NT (3.1) в 93м году. Помню дружное "а-а-АХ" нетварщиков на WinExpo93, когда на стендовом сервере под NT 3.1 (как сейчас помню - 486DX50 с 32Mb RAM) нажали Reset для демонстрации возможностей журнала в NTFS... Кто работал с тогдашней нетварью - поймет причину такого нервного аханья...;)

2anonymous (*) (2003-01-19 16:23:30.047): это была проблема NT4... Точнее не то чтоб проблема - соответствующие структуры данных были предусмотренны, а кода не было... Точнее был - от третих фирм.

anonymous (*) (2003-01-20 01:15:18.954):О! Наконец-то мелькнуло слово Veritas, здесь мало кому известное (ну что взять с красноглазых-то...;) А теперь рекомендую поискать его например на сайте мелкомягких, или сайте журнала виндовс мегазин... Узнаете много интересного откуда ноги у NTFS растут (кроме как из HPFS и т.д.)
Вообщем прежде чем рассуждать об NTFS стоит прочитать хотя бы http://msdn.microsoft.com/library/en-us/fileio/base/ntfs.asp а желательно и по ссылкам походить, чтоб вопросов и домыслов поменьше было...:)

Irsi
()

2 ifconfig >Блин, финансовая транзакция в ХХХ тыс. $ на писюке с проблемой в >питании на IDE харде...

Речь шла про raid c 256 M cache

Саныч

anonymous
()

2 All

Кто нибудь видел OpenLinux-3.1.1-Server ?

Кто что может сказать хорошего/плохого ?

Саныч

anonymous
()
Ответ на: комментарий от anonymous

2Саныч:
>Кто нибудь видел OpenLinux-3.1.1-Server ?
У меня есть - с Chip'ом диск шёл...

>Кто что может сказать хорошего/плохого ?
Всё как-то руки не доходят попробовать ;-)

Led ★★★☆☆
()

Начать надо, наверно, с того, что параллельно теме здесь идет весьма обширная дискуссия в [fido7.]ru.linux, результаты которой тоже имеет смысл глянуть.

Terry Lambert - никак не ведущий разработчик. Это интересный критик и сборщик информации, но не разработчик, по крайней мере для FreeBSD. Он вел несколько проектов для BSD вообще, базировался, кажется, на BSD/OS. Отношение к нему весьма неоднозначное, и это понятно. phk@ его недавно чуть ли не матом поливал;( "Клоун" для него - чересчур, скорее - старый зубр-ворчун, который всем недоволен и из которого при надлежащем подходе (немного лести;)) можно извлечь массу полезных данных.

Про пользу softupdates и чем оно лучше журналирующих систем - с полгода назад было интервью с Matt Dillon (to green@ - вот тебе еще одна действительно ключевая фигура) - кажется, оно и здесь упоминалось - и тогда что-то такого странного взрыва обсуждения не вызвало. В то же время Kirk McKusick ваяет UFS2, к которой softupdates + snapshots + background fsck являются предусловиями и составными частями, и эта работа финансируется DARPA, что показательно (см. список проектов DARPA;))

To green@: имя команды для write barrier в SCSI? Я такого не нашел. На самом деле там оно не нужно из-за прямой и давней поддержки тегов. Может, ты именно про теги?

Write cache лучше отключать везде, где требуется хоть какая-то надежность. К сожалению, на ряде ATA дисков оно не отключается. Конкретные модели упоминались во фрёвых рассылках при обсуждении ATA драйвера. Обычно умение ATA tags означает умение не врать про выключение кэша. Я на своих системах предпочитаю tags + no write cache. Самое тяжелое с write caching то, что у ряда дисков испорченный алгоритм оптимизации записи (минимум времени перемещения до следующего - вместо лифта), поэтому диски могут держать блоки в буфере часами. Какие модели - см. намек выше. К счастью, таких немного, и только для ATA.

To green@: про "зачем RELEASE": затем, что ветка, в которой действительно фиксится только критическое и не меняя функциональности - полезна для избавления админа от головной боли от мелких, но диверсионных для кого-то изменений. Поэтому у меня большинство систем - результат cvsup на RELENG_4_7 или RELENG_4_6. (Есть пара 4.4, есть одна 4.3 аналогичная. 4.5 нет - я ее боюсь.) Они при этом себя называют "4.7-RELEASE-p3" или аналогично. Идти по веткам RELENG_4 и тому подобным для STABLE сейчас обычно вредно: из-за огромной разницы между 5.0 и 4.* 4-STABLE сильно ухудшилась, тестировать невозможно. Впрочем, при наличии RELENG_x_y это не мешает работать. Если кто не понял, о чем я говорил - ищите "Введение в CVS" ;)

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

LFS жива в NetBSD. Надо спросить тамошний народ, хороша ли она. Но уже сейчас известно, что при заполнении диска выше 80% она превращается в сплошной тормоз.

netch
()

2 netch

Очень хотелось бы услышать Ваше ИМХО по таким вопросам:

1.

Гарантируетли ли такая последовательность команд

sync, ждем 2 сек, sync, ждем 2 сек, sync

то, что данные из всех кешей будут записаны на диски (8 шт) ?

У меня FreeBSD 4.7, softupdates on, write cache on,

scsi160 от Adaptec

2. Оценка потери производительности при write cache on/off.

Куча клиентов Samba одновременно пишет в 300-500 dbf файлов.

Спасибо

Саныч

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.