Интервью с Andrew Morton

чего то мне в лом было читать вдумчиво. по диагонали пробежал и так понял, что разговор шел о бо всем и ни о чем.
а вот чего мне на самом деле непонятно, зачем была сделана ext3?
поставил тут себе ее недавно и был сильно разочарован. Сразу оговорюсь, что надежность и скорость меня и на ext2 не утомляли.
просто хотелось быструю при проверке после резета файловую систему и желательно чтоб файлы > 2 GB.
а эта ext3 никак себя не проявляла. reiser сразу показался, xfs - хорошая история (но сейчас он на 18pre4 не пашет).
так что сейчас на рейзере, чуть попозже на xfs имеет смысл перейти. а на ext3 какой смысл?

потому что ее RH суппортит ;-)

SGI-шники сейчас в cvs не делают каждое 2.4.x-preY, только релизы.

Она хотя бы тем полезна что можно перейти на журналируемую файловую систему без форматирования раздела.

>SGI-шники сейчас в cvs не делают каждое 2.4.x-preY, только релизы.
ага. ждемс 2.4.18 без всяких пре.
а то у меня все нормально рулило, а вот апт курвился. %(
mmap sync чето там у него не шло.
но xfs имхо очень достойная штука и стоит того чтобы подождать.
тем паче что sgi вроде до сих пор не динамила и продукты очень интересные делала.

>потому что ее RH суппортит ;-)
это хорошо. но хотелось бы чего то более конкретного.
может быть кто то ее щупал посильнее?
чего я пропустил то?

Забавной фенькой представляется возможность журналирования не только meta-, но и просто данных. Правда, с соответствующим падением производительности.

А давайте возьмём интервью у green'а :)

>Она хотя бы тем полезна что можно перейти на журналируемую файловую систему без форматирования раздела.

Вообще-то на другие фс тоже можно перейти без переформатирования. Смотри список рассылки XFS, там шла речь о конверторе.

Журналирование данных не имеет практически никакого смысла если у программ нет доступа к API по управлению транзакциями и тп. Если журналирование метаданных позволяет нам полностью избегать запусков fsck, то с программами все сложнее: допустим некоторой программе в процессе работы необходимо изменить какой-то файл. Причем в одно обращение к write() это изменение не укладывается. Пусть будет 2 вызова write(). Теперь предположим что произошел crash после того как первый wriet был зажурналирован/записан. После того как система снова поднимется и журнал отиграется, мы получаем вроде-бы прекрасный и целостный файл без всякой потери данных? Но с точки зрения приложения этот файл поврежден! (например потому что количество записей уже увеличено, а новая запись не добавлена или еще что-нибудь в таком роде).

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

Назовем это SQLFS :)

>Журналирование данных не имеет практически никакого смысла если у программ нет доступа к API по управлению транзакциями и тп.

Почему нету? А fsync(2), fdatasync(2), sync(2) или ioctl(2) вроде тех что в xfs_bmap(8) для насильного приземления данных?

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

2Avel (*) (2002-02-12 23:44:01.0):

> а эта ext3 никак себя не проявляла. reiser сразу показался, xfs - хорошая история
Можно поподробнее?
Т.е., я не понял, чем reiser показался vs. ext3 ? Особенно в свете фразы
> надежность и скорость меня и на ext2 не утомляли.
Т.е., что, на ext3 надежность или скорость упали?

to Avel:: "а вот апт курвился. %( "
Что происходило? Я пользуюсь SID, и был период с месяц назад,
когда apt перестал работать, пришлось его удалить и поставить заново
(не помню, может из Woody), а сейчас все ок. 

Ядро 2.4.17-xfs. Файловая система _только_ xfs.

Вообще-то fsync(2) и sync(2) есть и у нежурналируемых файловых систем (ext2 например). Каким образом предлагается с их помощью реализовывать транзакции? Руками что ли?

Вообще-то это был один из примеров. А то мы так договоримся до того, чтобы все было ок, нужно не перезаписывать данные, а создать новый файл, туда внести все старые данныи с учетом всех изменений, а потом сделать rename(). (очень актуальный метод для апдейта одного байта в середине 10G файла)

>Что происходило?
unable sync mmap

>Ядро 2.4.17-xfs
на нем порядок. у меня 2.4.18pre4
xfs работает только на релизах.

>Т.е., я не понял, чем reiser показался vs. ext3 ?
я гоняю ext2/ext3 и рейзер на десктопе и серверах.
1)проблем с быстродействием FS практически не имею.
просто хотелось бы не иметь провалов на кривой зависимости скорости от нагрузки.
2)хочется быстрого бута и ребута. даже если был сбой.
3)хочется поменьше ограничений и побольше эффективности использования дискового пространства, дефрагментации и надежности. (проблем здесь у _меня_ не было даже на ext2, поэтому главное - не испортить и _желательно_ что то развивать.

reiser сразу дал все искомое и давно. работает стабильно, чек мгновенный. что еще надо?
1)отзыв господина Бокового, который заявил, что reiser непредсказуемо проваливает по скорости при плавном увеличении нагрузки. Для меня это знак.
2)хочется попользовать аклы под самбой и вообще пощупать их. Просто такое желание.

Все это присутствует в xfs. с выходом релиза 2.4.18 я буду ставить xfs и пробовать работать на ней.

>Т.е., что, на ext3 надежность или скорость упали?
нет. я просто не заметил перемен.
только .jurnal на всех разделах да ext3 в /proc/mounts
все остальное по старому. зачем мне ставить ext3 тогда?
я ж не юлюзмен, чтоб на новые ярлыки молиться, мне реальные преимущества подавай...

> Вообще-то fsync(2) и sync(2) есть и у нежурналируемых файловых систем (ext2 например). Ну понятно, что есть.

> Каким образом предлагается с их помощью реализовывать транзакции? Руками что ли? Разумеется. Другое дело, что жфс часто врут на fsync...

А позволит ли райзер4 откатываться назад по данным? Если нет - то речь скорее не о транзакциях, а о сохранении непротиворечивости данных приложения. Для чего журналирование данных не нужно.

Если руками реализовывать транзакции - то в чем смысл журналирования данных? Какие jfs врут на fsync()? (врут в плане того что после ребута мы видим совсем не то, что до ребута)

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

> Какие jfs врут на fsync()? > (врут в плане того что после ребута мы видим совсем не то, что до ребута).

Нет, речь идет о нормальном функционировании, без падения системы. На XFS sync(2) возвращается раньше, чем данные действительно были приземлены. Реже проявляется в ext3. Авторы GRUBa имеют с этим большие проблемы.

> Для сохранения непротиворечивости данных приложения журналирование данных нужно > (при возможности контроля приложением само собой) > иначе каким образом, например, переписывать часть данных в файле > (если эта часть заведомо больше одного блока)? Да, Вы правы, теперь я это вижу. А как бороться с такой ситуацией: Нужно атомарно записать кучу данных, а размер журнала слишком мал?

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

По поводу fsync() - если после ребута данные на месте (пусть даже и на другом) - то стандарт соблюден. никто не обещал что данные не переедут на другое место через некоторое время после fsync.

2Avel: Как это все по старому? У меня при некорректном гашении системы (например в результате сбоя по питанию) файловая система восстанавливается за секунду и без fsck.

> 2)хочется быстрого бута и ребута. даже если был сбой. 

Так ты и этого от ext3 не получил?

Я добавил жулнал на куче компов, но при отмонтированном разделе с ext2.
При этом журнал не виден, живет уже несколько месяцев. Загрузка всегда
мгновенная (после 'reset' на лету).

> По поводу fsync() - если после ребута данные на месте (пусть даже и на другом) - то стандарт соблюден. никто не обещал что данные не переедут на другое место через некоторое время после fsync.

Ну это верно теоретически, но неверно практически (какие фс так делают? не рассматриваем дефрагментацию по-живому, tail-packing(?) и т.п.). Причем, если ioctl(, FIBMAP, ) не возвращает блоки, которые в журнале, то никакого резона для такого поведения и нет.

Проблема в другом: sync(2) возвращается до того, как все данные действительно запишутся на диск.

Почему это мы не рассматриваем дефрагментацию по живому, тейл-пакинг и прочие полезные вещи? К тому же журнал не обязан находиться в строго фиксированных блоках.

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

Ну хвосты пусть живут :), а дефрагментации просто нет в линуксе. Только _растишка_ для ext2 по-живому есть вроде.

> (если они попали в журнал - то уже можно возвращаться из sync) Можно возвращаться из Fsync(2). Кстати, данные-то не журналируются - с чего из fsync(2) возвращаться? Речь о sync - он же одинаков для всех фс. Я думаю, это проблема (c sync(2)) именно в ext3(из-за jbd) и xfs(pagebuf). С райзерфс и ibm jfs такого нет.

Дефрагментации - пока нет. Но будет. Ok, где тестекйс демонстрирующий потерю данных после успешного sync(2) на xfs и ext3?

>> 2)хочется быстрого бута и ребута. даже если был сбой.

>Так ты и этого от ext3 не получил?
нет.
>Я добавил жулнал на куче компов, но при отмонтированном разделе с ext2.
>При этом журнал не виден, живет уже несколько месяцев. Загрузка всегда
мгновенная (после 'reset' на лету).

я добавлял когда был примонтирован. возможно в этом и есть проблема. однако уже после того я монтировал этот раздел вручную на ext3 и dmesg при загрузке говорит, что монтирует ext3.
при этом fsk ее проверяет в точности как ext2 %(

> Дефрагментации - пока нет. Но будет.
Вообще говоря, дефрагментацию по живому (как и изменение размера)
можно сделать для _любой_ файловой системы одним махом.

> Ok, где тестекйс демонстрирующий потерю данных после успешного sync(2) на xfs и ext3?
Например, смотрите http://mail.gnu.org/pipermail/bug-grub/
за февраль, ветка про ext3.

>>Журналирование данных не имеет практически никакого смысла если у >>программ нет доступа к API по управлению транзакциями и тп.

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

Кроме того писать программы под конкретную fs... :) как-то странно выглядит.

Сделайте дефрагментацию. Люди скажут спасибо.

По поводу тредов на http://mail.gnu.org/pipermail/bug-grub/ - что-то я там не заметил потери данных.

Программа, работающая с файлами должна знать о возможности аварии. А куда переносить средства поддержки транзакции - вопрос политический. Также как можно хранить данные программы в реестре или .cfg, а можно в EA файлов.

А насчет конкретной фс - есть же DMAPI.

рейзер проигрывает экст3 на файлах 2Г, разница в скорости 10 раз. На файлах больше 2Г по экспоненте

Я не говорил о потере данных. Ее и нет. А есть невозможность достоверно убедиться, что файл был приземлен - это после sync()! => нельзя правильно записать список блоков для загрузчика (он неполный получается или пустой).

А на дефрагментатор у меня нет времени и знаний о block layer мало, да и не хочется делать только дефрагментатор. Неживой конвертор/ресайзер до нормального вида довести бы...

Нет потери данных - следовательно буффера на диск попадают, следовательно sync отрабатывает строго по мануалу. Какие проблемы?

Есть такие приложения, авторы которых готовы заложиться на использование конкретной FS, лишь бы не переизобретать колесо и все такое.

Да нет... Из ветки про ext3: Данные попадают на диск, НО не до возвращения из sync(). Только после двух sync() (!) подряд можно быть уверенным, что данные на диске.

2Avel Не удержался и решил вставить свои пять копеек. Что значит "XFS _работает_ только на релизах" ? Чушь. Другое дело что выгладывают они патчики только для стабильных ядер. Потому как их CVS tree синхронизирован с последним релизом ядра. И пересинхронизируется оно по мере выхода новых. В принципе и правильно. Многие так делают. (например van Riel) А тем кому хочется иметь самую свежую имплементацию XFS + самое свежее ядро нужно ручками делать merge. В принципе - не так это и страшно. А если страшно - значит не больно то и хочется. Я вот например постоянно мерджу rmap <-> 2.4.18-preX. И XFS бы мерджил, только оно мне не надо так как я живу на reiser'e, а самые свежие пачти на reiser доступны для pre ядер.

Вот такие вот дела :) удачи в борьбе с XFS. -- With best wishes, Nick.

Да, и еще. тем кто живет на "ac" ядрах. в мердже rmap12a <-> 2.4.18-pre7 от Алана есть маленький глюк (правда безобидный совсем). Я ему уже об этом сообщил, но что то он пока еще это дело не поправил. Кому нужно 2.4.18-pre9-ac<X>-rmap12e (в том числе с исправленным глюком) могут взять патч вот здесь: http://den.st/nick/2.4.18-pre9-ac<X>-rmap12e.bz2 -- With best wishes, Nick.

>2Avel Не удержался и решил вставить свои пять копеек. Что значит "XFS
>_работает_ только на релизах" ? Чушь.

это значит, что поставить я все поставил, но mmap там глючит.
а в остальном работает :)

> Другое дело что выгладывают они патчики только для стабильных ядер.

вот про это я и говорил.

>Потому как их CVS tree синхронизирован с последним релизом ядра. И
>пересинхронизируется оно по мере выхода новых. В принципе и
>правильно. Многие так делают.

я тоже не в претензии.

>А тем кому хочется иметь самую свежую имплементацию XFS + самое >свежее ядро нужно ручками делать merge. В принципе - не так это и >страшно. А если страшно - значит не больно то и хочется.

на "посмотреть" и "потестировать".
я не могу все вокруг в ручную мержить. это просто нереально. у меня еще радеон есть, ваком есть, куча другого железа - здоровья не хватит все это мержить.

> И XFS бы мерджил, только оно мне не надо так как я живу на reiser'e, > а самые свежие пачти на reiser доступны для pre ядер.

вот эту разницу между xfs и reiser я и обозначил. поэтому сейчас я на рейзере...


>Вот такие вот дела :) удачи в борьбе с XFS.

спасибо :)

А я что-то не могу почитать интервью. Наверное убрали его уже.

Неа. Похоже сервак упал.

Ну сколько можно толочь воду в ступе? Если данные после креша, который сразу ппосле синка, не пропадают - то данные остались на диске! А то что они не там где их ожидают увидеть - так никто таких гарантий не давал!

Почему 2 sync()а подряд в ext3 решают проблему?

Какую проблему? Проблемы никакой нет. 2й синк реордерит файл на диске, в результате некоторые не совсем прямо написанные прилады вдруг начинают работать? Так при чем тут синк? Эдак до такого маразма можно докатиться, что представить страшно.

Но почему именно 2й, не 3й, не первый??? Почему такое же поведение на xfs? Она же не журналирует данные! Можете попробовать с той же версией груба. И почему этого нет на reiserfs?

Это называется realisation-dependant behavior или как-то так. Поскольку никаких стандартов это не нарушает, разработчики седлали так как им было удобнее.