ext4 - файловая система нового поколения.

Кстати, оказывается ext4 уже давным-давно есть:

http://www.cs.cmu.edu/~mihaib/fs/fs.html

Гы :)

>Кстати, оказывается ext4 уже давным-давно есть:

>http://www.cs.cmu.edu/~mihaib/fs/fs.html

>Гы :)

Copyright infringement! Будет новый судебный процесс!

>anonymous_incognito **** (*) (30.06.2006 20:27:54)

О.. Замечательно.. Давно уже пора..

> Во-первых текущее delayed allocation вунуждует fs делать это для каждой страницы, вместо для куска который дал write > The current ->prepare_write() interface shows its limits when having to >do hundreds of thousands (millions, even) of ->prepare_write() calls per >second.

патамушта тупые. потому, что ->prepare_write() и ->commit_write() должны что-то сделать _только_ для первой записи в страницу, когда она неаллоцирована или мы еще не знаем аллоцирована или нет. после этого ставится флаг в page->flags и оба ->{prepare|commit}_write() ее просто игнорируют. вы же не предполагаете аллоцировать миллионы страниц в секунду (1000000 * 4K = ~4GB/s) ?

>вы же не предполагаете аллоцировать миллионы страниц в секунду (1000000 * >4K = ~4GB/s) ?

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

кто писать это все будет на 4GB/s? fuse - это особый случай. ей performance, вроде как, не требуется особенный.

> Ну тоесть максимальный размер файла теперь будет больше 1 Tb?

Он не 1 TB, а 2 TB.

> А вот что в ext4 от нового поколения???

Extents + 48 bit + может еще чего добавят

> Нуну, вон reiser4 сколько уже ковыряют, а в ядро оно попасть никак не может.

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

> зачем изобретать велосипед? есть хфс - самая продвинутая фс,
токо данные может потерять при потере питания на x86 железе.

> оптимальный вариант для всех есть рейзер4 - с хитрыми фичами
Не для всех, фичи нужны определенные, а не хитрые, стабильность важнее хитрости. Поддержка предыдущих версий reiserfs от производителя reiserfs не добрая.

> ext4 - прошлого поколения!!! Очень сильно напоминает судороги perl6. Ничего революционного нет, а выделиться хочеться.

Никому не хочется, сходи по ссылке почитай прежде чем вякать.

> с сохранением совместимости ничего толком у них не получится.
будет ещё один монстрик с ещё одним костылём.

ути-пути аналитик выискался.


> Писец. Какой смысл начинать разработку новой ФС, если неясно, нах она вообще нужна? Имитация бурной деятельности и пеар?
> anonymous (*) (30.06.2006 14:16:21)

это была имитация возможности размышлять от анонимуса ?

>тото *BSDны мечтают о xfs/jfs, на худой конец zfs.

а что плохого в мечтах? по-моему мечтать - это хорошо.

не могу конечно за всех отвечать, но лично меня ufs2 полностью устраивает.

> не могу конечно за всех отвечать, но лично меня ufs2 полностью устраивает.

попробуйте как-нибудь на досуге запустить fsck на 8TB массиве с ufs2. понаблюдайте сколько времени это займет и насколько юзабельна будет машинка во время fsck.

>> зачем изобретать велосипед? есть хфс - самая продвинутая фс,
>токо данные может потерять при потере питания на x86 железе.

сказки трехлетней давности? да 3 года назад теряла. а с тех пор исправились, и отлично переносит внезапные выключения, не в пример рейзерам и ехт2.

к тому-же, тоже мне фича. а что ехт4 не будет терять данные с перебоями питания? _ГАРАНТИРОВАНО_ не будет терять?

да и кого это интересует на сервере вообще?

Объясните далёкому от IT ребёнку, что там будет особенного!

> к тому-же, тоже мне фича. а что ехт4 не будет терять данные с перебоями питания? _ГАРАНТИРОВАНО_ не будет терять?

угу, у нее как и у ext3 есть data=journal. чего нет у xfs/reiserfs.

> да и кого это интересует на сервере вообще?

другими словами "кто вообще на сервере данные хранит?"

> Объясните далёкому от IT ребёнку, что там будет особенного!

далекому долго очень объяснять

> угу, у нее как и у ext3 есть data=journal. чего нет у xfs/reiserfs.

4.2.

Во-первых, еще нет самой ext4, во-вторых, у reiserfs точно так же есть свитч data=journal.

>ext4 - прошлого поколения!!! Очень сильно напоминает судороги perl6. Ничего революционного нет, а выделиться хочеться.

Как минимум у ext3 три вида журналов и надежность выше крыши при том, что по скорости работы многие fs она делает.

Так что ext4 не может быть хуже по определению и значит, эта работа не пропадет даром, а станет массовым решением.

>А сколько плевались на NTFS за совместимость с FAT32...

У ntfs нет совместимости с FAT32. Из FAT32 можно более-менее просто сконвертить систему в NTFS.

При этом при разработке NTFS пришлось учитывать особенности FAT32, а они очень неблестящие (помнится, она соснула по скорости у всех fs во всех операциях, кроме удаления, где оказалась первой).

И из-за этого ее беды.

>Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут в основном благодаря отказу от их использования.

Неоптимально, пусть перепишет. Я еще помню, как третий не пускали из-за ужасного синтаксиса и не следования стандартам написания кода в ядро.

>Во-первых, еще нет самой ext4, во-вторых, у reiserfs точно так же есть свитч data=journal.

Есть, но почему-то с ним никто не тестирует производительность. А вот ext3 - всегда.

> Во-первых, еще нет самой ext4, во-вторых, у reiserfs точно так же есть свитч data=journal.

вы бы для приличия набрали ext4 в гугла, а?

http://www.bullopensource.org/ext4/

> Есть, но почему-то с ним никто не тестирует производительность. А вот ext3 - всегда.

Так на каком железе эти тесты гоняются? Стандартный размер журнала у рейзера 3.6 - 32М, из-за такого объема данных даже дергаться не тянет, благо размер кэша у любого приличного контроллера минимум в пару раз больше, а батарейку еще никто не отменял. А на десктопе во избежание извращений с журналами проще купить смарт-упс и резервный блок питания (как раз в цену виндов) и не париться :)

> вы бы для приличия набрали ext4 в гугла, а? > http://www.bullopensource.org/ext4/

И чего? Ааа, ага-счас, уже побежал накладывать патчи на рабочее ядро :)

Это "Ext2/Ext3 improvement project", столь же далекий от появления в продакшне как reiser4, разве что имеет больше шансов на включение в ядро. Вот когда будет включено, обезбажено, оттестировано, и т.п. как reiserfs и ext2/3 - тогда и речь вести будем.

Нужны массивы высокой емкости - есть _уже готовая_ xfs.

> тото *BSDны мечтают о xfs/jfs, на худой конец zfs.

Вообще-то о raiserfs/xfs ;-)

> Это "Ext2/Ext3 improvement project", столь же далекий от появления в > продакшне как reiser4, разве что имеет больше шансов на включение в ядро. Вот когда будет включено, обезбажено, оттестировано, и т.п. как reiserfs и ext2/3 - тогда и речь вести будем.

http://lkml.org/lkml/2006/6/9/418 :

"Umm, in case you didn't know, the extent patch which is the primary issue of discussion here (not the whole 64-bit clean changes though) were run for MILLIONS of hours under very high IO load on the largest computer systems in the world for the last year or so. It is easy to get millions of hours of usage if there are thousands of servers running this code..."

> Нужны массивы высокой емкости - есть _уже готовая_ xfs.

у которой нет и не будет нормального fsck. у которой ужастный код и, соответственно, поддержка kernel community.

> А на десктопе во избежание извращений с журналами проще купить смарт-упс и резервный блок питания (как раз в цену виндов) и не париться :)

вы просто не в курсе, что ups - это не панацея. бывают еще проблемы с памятью, бывают kernel panic/oops и так далее.

> http://lkml.org/lkml/2006/6/9/418 : > "Umm, in case you didn't know, the extent patch which is the primary issue of discussion here (not the whole 64-bit clean changes though) were run for MILLIONS of hours under very high IO load on the largest computer systems in the world for the last year or so. It is easy to get millions of hours of usage if there are thousands of servers running this code..."

Млять! Она в ядре? Еще нет? Нахер!

> у которой нет и не будет нормального fsck. у которой ужастный код и, соответственно, поддержка kernel community.

Обоснование "ужастного" кода в студию. Нахрена fsck файловой системе, которая выполняет восстановление при монтировании? Впадлу смонтировать в ro? Есть xfs_repair - траву бросать, курить маны ;)

> вы просто не в курсе, что ups - это не панацея. бывают еще проблемы с памятью, бывают kernel panic/oops и так далее.

Вам нужна 100% 12/7/24 надежность или за разумные деньги и соответственно задаче? ;) Если первое - то покупать систему с поддержкой горячей замены памяти, процов, винтов, блоков питания, и всего остального барахла вплоть до корпуса и материнок, man store.sun.com.

Кернел паник бывает, упсы бывают. Но разве на боевом сервере? На рабочей станции - такого не видел еще с 2.6.10, включая -mm, -rc и т.п. патчи. Причем не видел исключительно потому, что с 2.4 ветки перешел сразу на 2.6.10 :) Если кончилось ядро, то есть magic sysrq keyz, но в данной ситуации никто вообще не гарантирует сохранность данных, ибо смысл поведения - прекратить трепыхаться вообще, чтобы _запороть_ минимум.

> Млять! Она в ядре? Еще нет? Нахер!

это вы кому сказали? линусу? :)

> Обоснование "ужастного" кода в студию. какое нужно обоснование, если xfs была перенесена из другой ос с другим устройством и api. пусть переписывают на родное.

>Нахрена fsck файловой системе, которая выполняет восстановление при монтировании? Впадлу смонтировать в ro? Есть xfs_repair - траву бросать, курить маны ;)

вы просто никогда не сталкивались с реальными ситуация, когда storage корраптит блоки. когда никакой журнал не поможет по определению. xfs_repair - фигня из под ногтей.

> Вам нужна 100% 12/7/24 надежность или за разумные деньги и соответственно задаче? ;) Если первое - то покупать систему с поддержкой горячей замены памяти, процов, винтов, блоков питания, и всего остального барахла вплоть до корпуса и материнок, man store.sun.com.

это был ответ по существу? скорее маркетинговый булшит. может еще прайс сюда сунете?

> Кернел паник бывает, упсы бывают. Но разве на боевом сервере? На рабочей станции - такого не видел еще с 2.6.10, включая -mm, -rc и т.п. патчи. Причем не видел исключительно потому, что с 2.4 ветки перешел сразу на 2.6.10 :) Если кончилось ядро, то есть magic sysrq keyz, но в данной ситуации никто вообще не гарантирует сохранность данных, ибо смысл поведения - прекратить трепыхаться вообще, чтобы _запороть_ минимум.

ага точно, назвал сервер боевым, поставил .x >= 10 и все, никаких паников. похоже на самогипноз.

> Если кончилось ядро, то есть magic sysrq keyz, но в данной ситуации никто вообще не гарантирует сохранность данных, ибо смысл поведения - прекратить трепыхаться вообще, чтобы _запороть_ минимум.

твой собственный тезис про ненужность журнала на десктопе напомнить? в случае с panic/oops он нужен, ибо позволяет обойтись без fsck.

> это вы кому сказали? линусу? :)

Нет, некоему лицу, сомневающемуся в фразе "еще нет самой ext4" ;) Даже ext3dev еще нет, одни названия.

> вы просто никогда не сталкивались с реальными ситуация, когда storage корраптит блоки. когда никакой журнал не поможет по определению. xfs_repair - фигня из под ногтей.

Нафига вообще использовать такой глюкавый сторейдж? Ситуация скорее нереальная, т.к. по определению прежде куда-то что-то писать - неплохо бы проверять носитель ;) А чем поможет fsck в таком случае - прибьет ФС окончательно?

> это был ответ по существу? скорее маркетинговый булшит. может еще прайс сюда сунете?

Сказал же - man store.sun.com ;) По существу - если на рабочей системе используется столь говенное, да к тому же видимо еще и заведомо бракованное железо, то это явно не недостаток файловой системы ;)

Блин... SUN и маркетинг... спасибо, посмеялся :)

> ага точно, назвал сервер боевым, поставил .x >= 10 и все, никаких паников. похоже на самогипноз.

Прикол из раздела с самопроизвольно корраптящимися носителями? ;) Помойму с ОЗУ дела еще хуже, там это "бай дизайн" %)

На самом деле - все просто, не зря было сказано - "на рабочей станции". А если уж добрый сэр вспомнил слово "сервер" - то на RHEL4 используется 2.6.9, но оно не vanilla, поэтому я его и не упоминал. Ф детсад ;)

> твой собственный тезис про ненужность журнала на десктопе напомнить? в случае с panic/oops он нужен, ибо позволяет обойтись без fsck.

Да-да, еще желательно обосновать принадлежность его мне.

А еще желательно пояснить, зачем были претензии к отсуствию fsck у xfs, если журнал и устройство драйвера этой ФС все равно позволяет обойтись без него.

> Прикол из раздела с самопроизвольно корраптящимися носителями? ;) Помойму с ОЗУ дела еще хуже, там это "бай дизайн" %)

и правда в детсад. похоже ни с чем, окромя hdd за $100 дела не имел.

> А еще желательно пояснить, зачем были претензии к отсуствию fsck у xfs, если журнал и устройство драйвера этой ФС все равно позволяет обойтись без него.

прикинь, несоблюдение температурного режима легко приводят к порче данных. а в firmware hdd бывают ошибки, тоже приводящие к порче данных. это будешь тоже журналом чинить, баклан?

> и правда в детсад. похоже ни с чем, окромя hdd за $100 дела не имел.

Воистину так, о многомудрый :) Только вот 100 - это нижняя планка, да и больше не с hd{a,b,c,d}, а sd* как-то сложилось ;)

> прикинь, несоблюдение температурного режима легко приводят к порче данных. а в firmware hdd бывают ошибки, тоже приводящие к порче данных. это будешь тоже журналом чинить, баклан?

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

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

Если косяк в фирмвари - после замеченных ошибок Вам вендор заменит всю партию, да и бакап, опять же, никто не отменял.

Ты мне другое скажи, о водоплавающий благородных пород, на кой черт продолжать эксплуатировать заведомо неисправный носитель? Или логику этой фразы стоит расписать подробнее? ;)

Хех, одного не понимаю: неужто доки нынче не в почете, а админы предпочитают самообразовываться через ЛОР... куда катится мир... %))

> Если косяк в фирмвари - после замеченных ошибок Вам вендор заменит всю партию, да и бакап, опять же, никто не отменял.

а, так вы из этих, из теоретиков? ну давайте, дальше теоретизируйте.

> а, так вы из этих, из теоретиков? ну давайте, дальше теоретизируйте.

Именно из тех... привык сначала думать, а потом делать ;) Успехов месье в вопросах перманентного костылестроения...