В обсуждении текущего состояния файловой системы ext3 в списке рассылки LKM были перечислены (http://lwn.net/Articles/186754/) некоторые недостатки (http://www.bullopensource.org/ext4/) ext3 от которых давно хочется избавиться.
Главная цель - переход на 48 (http://ext2.sourceforge.net/48bitext3/) или 64-битные (http://www.bullopensource.org/ext4/) указатели, текущий лимит на размер раздела в 8 TB уже многих не устраивает.
Theodore Ts'o, один из основных разработчиков ext2/ext3, предлагает (http://kerneltrap.org/node/6776) не резать по живому, а оставить код ext3 доступным только для исправления ошибок. Для реализации новых идей планируется на базе кода ext3 создать экспериментальную файловую систему ext3dev, которая после перехода в стабильную фазу будет переименована в ext4 (http://www.bullopensource.org/ext4/).
Основные опасения прямой модификации уже достаточно хорошо отлаженного кода ext3 связанны с понижением стабильности, нарушением совместимости и усложнением кода.
URL: http://kerneltrap.org/node/6776
Новость: http://www.opennet.me/opennews/art.shtml?num=7809
Нда... В каким же монстром станет эта ext4, если будет поддерживать работу с разделами ext3
это вы просто неграмотный совсем. читайте lkml. для поддержки нового формата потребовалось три if'а в старом коде и один новый файл.
Интересно комуто из присутствующих надо раздел > 8 TB ?
Не все "суперхацкеры" за домашним компом.
И за домашним уже скоро. У меня 2TB.
МНЕ!8Тб = 500*16. Т.е. 16 дисков по 500 Гиг. 500 Гиг уже в продаже, а через год, два они будут в любом декстопе. А дисковые полки по 12-15 дисков уже норма в серверных.
Надо, надо поддержку разделов более 8 ТБ!
А что нет уже готовых файловых систем которые более удовлетворяют современным требованиям. Может лучше в них вложить ресурсы?
Совершенно согласен. Лучше бы взялись за merging reiser4 и доработку VFS.
возьмите и доработайте этот over-designed monster.
Ой, ну как же я его доработаю. Я ж из простых, из деревенских. А тут настоящий кернел-хацкер нужен. Типо вас, наверное...
>А что нет уже готовых файловых систем которые более удовлетворяют современным требованиям.
>Может лучше в них вложить ресурсы?есть, называется ext4. для приличия внимательно пост прочтите и по ссылкам сходите,
преждем чем ахинею нести.
Reiser4 или reiserfs гораздо лучше.2TB это >=5HDD дома?
Теперь уже всего 3х750G .... А уж что следуюшим летом будет ....
Ну почему же сразу монстром? Добавится полноценная поддержка 64bit-платформ, новые 64-битные указатели, правда до максимума возможностей этой системы уже очень трудно будет дойти (34`359`738`368 Тб вам не шутки). А насчет > 8 Тб, да, бывает требуется, не мне, но работающим с СУБД Oracle. Там БД в пол терабайта является базой среднего размера, а уж дойти до 8 - не проблема. Потому в свое время Oracle и пошла на разработку своей ФС.
А как насчет той же ZFS?! "The file system itself is 128-bit, allowing for 256 quadrillion zettabytes of storage" Solaris ZFS Administration Guide, может стоит присмотреться к другим файловым системам ИМХО
Месье уже перенес ZFS под Линукс?
вам никто не мешает. приматривайтесь. а другие научились фильтровать булшит наподобие этих 128 бит.
>вам никто не мешает. приматривайтесь. а другие научились фильтровать булшит наподобие этих
>128 бит.Слушай, очередной Анонизм!
Ты сам не пробовал эту файловую систему (ZFS). Так что не позорь то, о чем не знаешь.
я сам читал о ней много. в том числе on-disk format. 128bit - это marketing BS. не нужно это никому на практике. вообще никому.
>я сам читал о ней много. в том числе on-disk format. 128bit
>- это marketing BS. не нужно это никому на практике. вообще
>никому.О, а не поделитесь этим самым on-disk format ? Интересно почитать.
у меня уже есть 4 по 500G, так что более 8T это еще как надо!!!!
Интересно что на этих 2T хранится, неужели зеркало sourceforge? А может все банальнее - порнуха?
Нормальному пользователю хватит и 80Gb, все остальное - суета, или для серверных решений.
> Нормальному пользователю хватит и 80Gb, все остальное - суета,ftp://ftp.andr.ru/pub/music/
ftp://ftp.andr.ru/pub/video/
гуд, подержи плиз еще открытыми эти шары )) я там се че-т пресмотрел
Большие хранилища - уже отнюдь не суета, а насущная необходимость, вызванная развитием местных IP-сетей. Сегодня, продавая доступ в сеть, домушник или провайдер не может не дать доступа к хранилищу тех же фильмов. Да и у меня на работе резервный бэкап собран из 8х250, а хочется 16х500 - в связи с производственной необходимостью.
что мешает использовать XFS ? там и громадные разделы и файлы
http://oss.sgi.com/projects/xfs/
мешает то, что она ужастно написана и у него никакой fsck, без которого не обойтись, если
storage корраптит метаданные.
в ZFS тоже не нужен fsck,но она от этого не страдает, там есть Transactional Semantics и никакое выключение питание вам не страшно. А востановление так есть Self-Healing Data.
бла-бла-бла. вы говорите про "бумажную" систему. никто ее еще серьезно не тестировал. а по части performance уже показано как она конкретно сосет. даже по сравнению с ufs.
Вот вы гврите что не тестировали серьезно, а потом что сосет по части performance, ну тогда как можно опираться на не серьезные факты?! Да и раз не тестировали не значит что плохая.
серьезно - это значит долго по времени и на разных приложениях. вот будет ей несколько годков в production, тогда да, серьзено. а performance уже меряли. сосала. так что работать над ней еще и работать.
может я плохо знаю историю, но не помню ничего что выпустила бы Sun и это потом сосало
да много чего. scheduling activations, например. или priority paging.
> и у него никакой fsckЭто у Вас мозг никакой...
xfsutils - да, да, да... только там надо головой и ручками поработать, а не только ими за письку дёргать.
давайте-давайте, работайте-работайте, ищите иноды в нескольких TB. и еще научитесь наконец обгонять ext3 в dbench. и покажите мне xfs, записывающую 1,5GB/s. потом и махайте руками.
тогда JFS, fsck у него есть и отлично работает.
http://www.bullopensource.org/ext4/
всё это прошлый век. повторяют одно и тоже, ничего нового
сейчас уже по сети можно качать гигабит, а скоро можно будет все десять.
современная fs должна быть: безопасной; распределённой; отказоустойчивой.
это значит:
1) средстваа шифрования должны быть встроены в саму ось
2) длина провода до винтов и протокол обмена
с ними не должны иметь значение. т.е. fs должа
поддерживать монтирование девайсов по сети по любым
доступным протоколам и проводам без посредников.
3) средства избыточного кодирования и восстановления данных
(RAID) втроены в саму fs, включены и работают по-умолчанию
(как и шифрование)
вот тогда это будет нечто. а эти ребята пальцем в носу ковыряются.вот есть нечто похожее, xFS и кластер NOW http://now.cs.berkeley.edu/Xfs/xfs.html
да, вы забыли, что она еще картошку должна чистить. www.lustre.org. живет поверх ext3. ибо layring.
Интересно что на этих 2T хранится, неужели зеркало sourceforge? А может все банальнее - порнуха?
Нет не порнуха, все банально там бэкапы лежат
> Нет не порнуха, все банально там бэкапы лежатА бэкапы не порнухи ли лежат ? :)
Чуваки, у меня уже 0.5 Tb дома.До восьми осталось ждать не сильно долго.История как почти с FAT16 - он тоже больше 2 гиг не умел.А когда-то 2 Гб казались такой огромной кучей данных...P.S. мне нравится Reiser4 - достойный ответ NTFS и провалившимся потугам сделать WinFS.Пример современной файловой системы с нормальным, эффективным и фичастым а не допотопным дизайном :)
единое дерево - это очень плохо для scalability. собственно v3 это уже продемонстрировала - v3 работает плохо на SMP (особенное если кол-во cpu >2) и кушает это cpu значительно, то есть для streaming writes типа видио/аудио подходит плохо.
Чушь. Дело не в едином дереве, а отсутствии механизма блокирования узлов. В reiser4 эта проблема решена.Более подробно на русском:
про reiserfs см. http://www.filesystems.nm.ru/reiserfs_layout.pdf
про reiser4 см. "Системный администратор", апрель 2006, стр. 16-25.
да-да, решено. вот покажут 1GB/s на одном камне, тогда решено, а пока только слова.
А кроме raw I/O кто-нибудь может показать такую пропускную способность?
да, сам видел на ext3 + extents + delayed allocation. underlying storage - DDN9500.
Думаю, reiser4 и XFS покажут себя не хуже.
тут все просто. сначала пусть показывают, потом руками машут. xfs, например, сливает ext3 в dbench.
смешно. сначала создают проблему, потом пытаются решить. "наши люди"
Ну так пусть 1 CPU занимается файловой системой а остальные другим, как будто 1 CPU с файловой системой не справится.А так - рейзер кстати вроде и не позиционируется для особо-крутых стриминг серверов.А вот для 100k мелких файлов - самое оно.Покажите что-то лучше для хранения 100k файлов?А будете наглеть попрошу чтобы в 1 каталоге к тому же :)
вот на ext3+extents+delalloc+mballoc выжали порядка 1,2GB/s. покажите мне reiserfs, которая столько даст. со 100K в одном каталоге _легко_ справляется ext3. dir_index включите.
Как-то не прозвучало аргументированных возражений против надёжности, масштабируемости и быстродействия XFS и JFS. Так что, Ext4 - это просто развитие Ext3 (необходимое почитателям Ext3) или это насущная необходимость для всех, потому как в природе пока ничего подобного нет (я имею ввиду Линукс)? Под XFS+Oracle работают базы размером около 10Т без проблем (на хорошем железе). Итак?
ext4 - это развитие ext3. jfs/xfs не являются _очень_ надежными просто в силу динамического характера метаданных (инод). результатом этого динамического размещения является на порядок более слабый fsck, по сравнению e2fsck. по сути против этого на lkml не было возражений. плюс обе xfs/jfs перенесены в linux посредством выстраивания дополнительного уровня. это тоже плохо. код у обоих просто ужасен. есть достаточно людей заинтересованных в развитии ext3. если кому-то интересна xfs - пусть развивают.PS. http://www.xy1.org/linux-kernel@vger.kernel.org/msg0187...