8 июня 2008 в 02:02

ext4: Еще тестируется или уже работает?


В анонсе Fedora 9 в одной из первых строчек упоминается о экспериментальной поддержке файловой системы ext4.

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



Чем лучше ext4


  • ext4 быстрее, особенно при работе с большими файлами (очень заметно при удалении).
  • размер файла — до 16Т, файловой системы — до 1024Р
  • появились «расширенные атрибуты в inode» для SElinux, beagle, samba. В определённых ситуациях могут ускориться mkfs и fsck.
  • Можно просто монтировать имеющиеся разделы ext3 как ext4
  • Разрабатывается дефрагментатор наподобие имеющегося в XFS. Он будет уметь: собирать файл в непрерывную область, собирать файлы из одной директории вместе, собирать пустое пространство в непрерывную область. Производительность при этом должна возрастать

Технические детали читайте здесь: ext4 на русском,
New ext4 features.

Как перейти с ext3 на ext4


В production-варианте ext3 можно будет смонтировать как ext4. Сейчас процедура немного сложнее.
Пускай на диск /dev/sdc1 у нас установлена ext3. С помощью blkid видим как идентифицирует файловую систему ядро.
[root@ad mnt]# blkid /dev/sdc1
/dev/sdc1: LABEL="/var/www/img" UUID="77d69541-cd2e-47d5-91fc-bdb5606aa8fb" SEC_TYPE="ext2" TYPE="ext3"


Пока у нас будет TYPE=«ext3», мы не сможем подмонтировать диск под ext4. Фиксим эту проблему
[root@ad mnt]# debugfs -w /dev/sdc1
debugfs 1.40.8 (13-Mar-2008)
debugfs:  set_super_value s_flags 4
debugfs:  quit


проверяем:
[root@ad mnt]# blkid /dev/sdc1
/dev/sdc1: LABEL="/var/www/img" UUID="77d69541-cd2e-47d5-91fc-bdb5606aa8fb" SEC_TYPE="ext2" TYPE="ext4dev"


Тут нет ошибки, сейчас файловая система называется ext4dev.

Можно монтировать:
[root@ad mnt]# mount -t ext4dev -o extents /dev/sdc1 ./test


Как форматнуть раздел под ext4


# mke2fs -E test_fs /dev/sdc1
# tune2fs -j /dev/sdc1


Где уже сейчас разумно использовать ext4


Могу сказать точно, что не в директории /var/lib/mysql.
Я уже сейчас использую ext4dev, в разделе где складывается кеш nginx, а также весь фото-контент (при отдаче статики для nginx важна скорость работы с файловой системой).

Чтоб не рисковать, я менял файловую систему путем форматирования и заливки контента на чистый диск. Во время этой процедуры случился небольшой курьёз. В ext3 все файлы занимали 97G, после перезаливки на новый отформатированый раздел ext4dev получилось 90G. Врубил сравнение папок в mc, сравнивало полдня — все Ok :). Почему произошла экономия я сейчас сказать не могу, возможно, данные на ext3 были сильно фрагментированы (там было очень много директорий с мелкии файлами).

Какие риски?


Риски очевидны, это экспериментальная поддержка — возможно все!
При переходе с ext2 на ext3 в любой момент можно было отказаться от ext3 и подмонтировать ext3 как ext2, если вы уже перешли на ext4 — назад дороги нет!
Можно монтироваться с опцией -o noextents и тогда будет возможность откатить все в ext3, но эта опция отрубает практически все прелести ext4.

В случае «слета» файловой системы нужно быть готовым к применению tune2fs.

Может быть вы уже решились перевести директорию /tmp на ext4 :)?

UPD1: Чтоб работал fsck нужно скопировать fsck.ext3 в fsck.ext4. Теперь пожем запускать
# fsck.ext4 /dev/sdc1

Олег Черний @apelsyn
карма
179,1
рейтинг 0,0
Разработчик
Похожие публикации
Самое читаемое Администрирование

Комментарии (36)

  • +25
    Первый пост на хабре за долгое время, который реально интересен, полезен, нескопипастен, грамотно написан, хорошо оформлен - и всё это вместе.
    Ай, нравица!
    • 0
      Хабракат быть может? :)
      • +4
        Отсутствие хабраката тоже имеет свои плюсы: статья целиком попала в RSS :)
        • 0
          Ночью размещал, за habracut забыл. Уже поправил.
      • –1
        Нет. Кричать "спрячьте под кат" хочется только статьям, неинтересность которых определяется по первым же строкам.
    • +1
      Хоть я и далёк от Линукса, но пост действительно хороший. Помимо сведений о ext4, есть авторские сооброжения, советы и небольшой эксперимент. Чувствуется научный подход.
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Ну неплохие посты всё же были — что Вы так пессимистично :). Но всё же тут отличное, новое и авторское сравнение и анализ :).
  • +1
    Пост написан грамотно. Автору медаль. Тема к тому же весьма интересная. Вопрос ко всем, не только к автору. Существует ли поддержка других файловых систем кроме FAT и NTFS в Windows? Как то если честно производительность их меня не очень устравивает, да и в других областях они кое-где уступают другим ФС вроде XFS, ReiserFS, Ext2, Ext3, Ext4 и т.д.
    • 0
      В виде «хака» есть драйвер для ext3. По быстрому скопировать файл можно с помощью утилиты explore2fs. Но официально конечно же поддержки нет. В production можно использоватль только FAT или NTFS.
      • 0
        вроде когда-то был установщик поддержки winfs.
    • 0
      >Существует ли поддержка других файловых систем кроме FAT и NTFS в Windows?

      Пользуюсь постоянно:
      http://www.fs-driver.org/ - Ext2 Installable File System For Windows
      http://sourceforge.net/projects/ext2fsd - Ext2 File System Driver for Windows

      Прочие:
      http://rfsd.sourceforge.net/ - ReiserDriver is an Installable File System Driver (IFSD) that allows ReiserFS partitions to be accessed under Windows
      http://www.crossmeta.com/crossmeta.html
    • +1
      А чем вас не устраивает ntfs, можно поподробней ? Вот если посмотреть сюда: http://ru.wikipedia.org/wiki/Сравнение_файловых_систем , - становится видно что xfs, ext или reiser ни граммом не лучше ntfs: xfs не умеет временные метки, максимальный размер файла/тома 9ебибайта; ext2/3 имеют максимальный размер тома в 32 террабайта (не смешно ли =)), так же не умеют временные метки; reiserfs4 вообще не умеет ACL, MAC и расширенные атрибуты (альтернативные потоки); как ни странно ntfs умеет и временные метки, и ACL, и MAC, и расширенные атрибуты, и снапшоты, и компрессию фс, разве что только POSIX права не умеет (по понятным причинам, хотя оно ей и не нужно). Кстати о фрагментации, работая с FreeBSD/Solaris UFS самый высокий уровень фрагментации виденный мною - 5%. У линуксов так всё плохо или уважаемый Forever понятия не имеет о чём говорит ? Скорее последнее. К фрагментации ntfs так же ровнодушна, на её производительности оно существенным образом никак не сказывается. Единственная фс которой ntfs таки сливает по всем статьям (так же как и все остальные) так это последняя файловая система для человечества - zfs, да и то в основном из-за её обескураживающих менеджмент тулз :)

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

      ps: вполне допускаю что данные в ссылке устаревшие и скажем, например, reiserfs4 таки мог обзавестить ACL и MAC, т.к. 3ий оба умеет.
      • +1
        Самое главное, что меня не устравивает в NTFS это скорость работы. Речь шла не о выборе самой лучшей ФС. Мне просто нужна ФС на которой можно хранить фильмы, музыку и всякий другой бред и которая должна работать как можно быстрее. А такая хрень как ACL, MAC вообще не интересует. Еще разок повторюсь, я не ищу замены NTFS и пока не собираюсь полностью от нее отказываться.А насчет фрагментации ты не прав. Любая ФС подвержена фрагментации в той или иной мере, и скорость работы при этом очень сильно падает.
        • 0
          А еще в Vista была добавлена поддержка новой ФС exfat (расширение FAT32). Она сохранила многие хорошие качества FAT32 и избавилась от некоторых ее недостатков. Однако ведет она себя иногда очень странно. Как появится свободное время - нужно будет протестировать.
          • 0
            Очнитесь. XXI век на дворе. кому нужна File Allocation Table ?
            http://ru.wikipedia.org/wiki/ExFAT ,- "файловая система для флеш-дисков... Используется в качестве замены FAT в тех случаях, когда использование файловой системы NTFS нецелесообразно." Только клинический идиот додумается использовать fat, когда можно использовать ntfs.
        • 0
          омж. Читайте: "Все внутренние структуры построены таким образом, что фрагментация не мешает быстро находить фрагменты данных.", - отсюда http://www.ixbt.com/storage/ntfs.html. Я не сказал что она не подвержена, я сказал что она "ровнодушна". Вопрос физических последствий фрагментации ntfs у аппаратной части относится к аппаратной части, - например на SSD дисках это не имеет физического смысла. Касательно суждения "любя фс...": http://ru.wikipedia.org/wiki/Zettabyte_File_System - в первом же абзаце: "Основное преимущество ZFS — отсутствие фрагментации данных, что позволяет...". Теперь о суждении "и скорость работы при этом очень сильно падает": в частности BSD UFS слабо подвержена фрагментации, как может пострадать скорость работы если фрагментации раздела более 5% не бывает ? ))
      • +4
        ntfs это неплохая файловая система, но по скорости работа она в сравнение с ext4 не идет. Я взял самые простые результаты сравнения файловых систем, поскольку они на английском, приведу здесь и прокомментирую:

        Все тесты проводились 5 раз и представлены усреднённые результаты:
        * В первой колонке указан тест на использование дискового пространства. Были взяты исходники 3 разных копий ядра linux. Чистый размер без метаданных составил 655MB
        * Copy 655MB (1): Копирование данных внутри раздела диска
        * Copy 655MB (2): Копирование данных на другой раздел
        * Tar Gzip 655MB: Tar and Gzip the data. Пакуем tar.gzip
        * Unzip UnTar 655MB: UnGzip and UnTar the data. Распаковуем tar.gzip
        * Del 2.5 Gig: Уделение файла (около 2.5 Gig).


        Делаем анализ. Смотрим EXT4 extents и ntfs.

        * ntfs экономичнее: 779 против 806
        * копирование файла внутри раздела, ну здесь полный провал - почти в 5 раз медленее!
        * копирование на другой раздел, ext4 быстрее

        К сожалению по остальным тестам результатов нет, на фоне вышеописанного я бы не говорил что ext4 не удалась, да и raizer4 tails посолиднее выглядит.
        Кроме того около половины технологий в системе пока не реализованы, в том числе и временные метки, которые есть в ntsf, об этом подробно написано в русскоязычной ссылке на ext4.


        .-------------------------------------------------.
        |File |Disk |Copy |Copy |Tar |Unzip| Del |
        |System |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
        |Type | (MB)| (1) | (2) |655MB|655MB| Gig |
        .-------------------------------------------------.
        |REISER4 gzip | 213 | 148 | 68 | 83 | 48 | 70 |
        |REISER4 lzo | 278 | 138 | 56 | 80 | 34 | 84 |
        |REISER4 tails| 673 | 148 | 63 | 78 | 33 | 65 |
        |REISER4 | 692 | 148 | 55 | 67 | 25 | 56 |
        |NTFS3g | 772 |1333 |1426 | 585 | 767 | 194 |
        |NTFS | 779 | 781 | 173 | X | X | X |
        |REISER3 | 793 | 184 | 98 | 85 | 63 | 22 |
        |XFS | 799 | 220 | 173 | 119 | 90 | 106 |
        |JFS | 806 | 228 | 202 | 95 | 97 | 127 |
        |EXT4 extents | 806 | 162 | 55 | 69 | 36 | 32 |
        |EXT4 default | 816 | 174 | 70 | 74 | 42 | 50 |
        |EXT3 | 816 | 182 | 74 | 73 | 43 | 51 |
        |EXT2 | 816 | 201 | 82 | 73 | 39 | 67 |
        |FAT32 | 988 | 253 | 158 | 118 | 81 | 95 |
        .-------------------------------------------------.
        • +1
          Ничего себе. За последние пару дней чтения этого ресурса едва ли не первый достойный коммент :) Ткнул плюсик, но кажется я не умею ещё их ставить.
          Однако, "провальной" ext4 я назвал по отношению к ext3, конечно, как к близжайшему родственнику, а провальная потому что какие бы то ни было внутренние перестановки никак особо не изменили саму фс. Да, на грамм шустрее ext3, но это не оправдывает трудозатраты на её разработку. Ну это моё личное мнение. Возможно тут я не прав. Касательно ntfs, имея опыт администрирования Windows 2003 Server, могу сказать что ниразу фс не становилась узким местом для MS SQL, Exchange, IIS (www, ftp). Узким местом чаще становились дерьмовые винты и контроллеры на которых любили экономить. А уж на домашней висте я вообще ниразу не задумывался на тему "ой, как-то долго это копирует": ведь дома есть гораздо более важные дела чем замеры с секундомером копирования файлов, например игры или просмотры пирацких видеофильмов ^_^
          Я собственно к чему это всё.. К тому, что нет смысла в чём то отличном от ntfs для Windows как минимум пока до тех пор пока по совокупности "плюсов" это самое что-то отличное не переплюнет текущую ntfs хотя бы на две головы, а когда это появится, MS не стесняясь либо купить разработку/всю_контору, либо сделает свою реализацию... А сейчас MS ещё может быть разродиться своим WinFS костылём и вообще настанет вселенское счастие :)
      • 0
        Можно чуть подробнее про 'xfs не умеет временные метки', мы наверное разное подразумваем под временными метками. Это не timestamp?
      • 0
        У тебя есть сервак с хардом >32 террабайта? И вообще они часто встречаются?
  • 0
    т.е. на десктопы лучше не ставить? спасибо, а то с дуру уже хотел попробовать.
    • +3
      почему же, вы вполне можете смонтировать / как ext4 и, по идее, получить прирост производительности небольшой, хотя основная плюшка вырастет с того момента, когда вашей системе хотя бы beagle начнет пользоваться новшеством. Главное /home оставить в чем-нибудь удобочитаемом-после-краха. (если ваши рабочие данные в /home)
  • 0
    /tmp и всякое такое лучше в tmpfs держать
    • +1
      Я предложил вариант, где можно попробовать работу файловой системы без особого риска для всей системы.
      Никто не сомневается что с tmpfs, которая использует оперативную память будет работать быстрее.
  • 0
    что-то мне не понравилась фраза "Разрабатывается дефрагментатор". Что значит, периодически нужно будет пускать дефрагментаци? Я так был щаслив, уходя с винды, зная, что все, у меня в gentoo стоит reiserfs и не надо никакой дефрагментации... а тут вон оно что выходит.
    • 0
      почему вы считаете, что в ReiserFS нет проблемы фрагментации?
      • 0
        ну хотябы по тому что я не встречал средств дефрагментации, следовательно я считаю если фрагментация присутствует - то она незначительная. Мысли вслух - жаль, безмерно жаль, Ганса Райзера... если увидим reisrefs4 то не скоро.
        • 0
          Их действительно нет, их нет и для ext3, хотя там проблема фрагментации гораздо более выражена. В ext дефрагментация нужна, хотя и далеко не в степени, которая нужна скажем, FAT.
    • 0
      Проблема фрагментации есть везде. Вверху я дал ссылку на русскоязычную статью по ext4. Посмотрите раздел "Дефрагментация".
  • 0
    о. давно слышал про ехт4, да особо без подробностей.

    А насколько серьезна проблема фрагментации в ext3? В райзере, насколько знаю это ен сильно тормозит работу
    • 0
      Она серьезна для time-critical сервисов, в 90% случаев она даже на процент производительности не должна сказываться, ИМХО.
  • 0
    Спасибо, интересная статья. Но пробовать пока не стану :)
  • 0
    а что в ext3 удалить большой файл это долго?
    я не знаю, я с ними не работал, но в ntfs — это мгновенно делается. проблема в ntfs обычно при удалении большого количества файлов — долго очень.
    • 0
      ext3 очень многие вещи делает по-другому, удаляет она, например, записывая нули в указатели блоков, которых имеется на каждые N байт "файла".
  • 0
    Может быть вы уже решились перевести директорию /tmp на ext4 :)?

    Особого смысла в переходе для себя не вижу, только интерес. "Побаловаться", так сказать. :)
    Но вполне можно поэксперементировать на мусоре (не жалко) — думаю, и с /tmp можно взять свои выводы.

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