LINUX.ORG.RU

Интервью о состоянии поддержки ext4 в Fedora 9

 , , , ,


0

1

Один из разработчиков — Эрик Сэндин (Eric Sandeen) — дал интервью о состоянии поддержки файловой системы ext4 в готовящейся к выходу 9-й версии дистрибутива Fedora. Основные моменты:

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

>>> Интервью на английском

★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от timur_dav

Соклько не менял ФС - ни разу не заметил прироста скорости. Какие-то там проценты - фиг с ними, главное, что Ext3 - единственная ФС, которая учитывает, что PC hardware sucks.

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

ext3 очень печалит, когда я вхожу в каталоги типа /usr/share/doc или /var/lib/dpkg/info и /usr/lib. Нееет, такого безобразия терпеть нельзя. И это не зависит от того, на каком железе это работает. Даже на SSD тормозит.

timur_dav ☆☆☆☆☆
()
Ответ на: комментарий от KRoN73

>>> Выбор FS - это очень религиозная штука :)

Абсолютно верно.

timur_dav ☆☆☆☆☆
()
Ответ на: комментарий от vadiml

>Думаю что при включенном NCQ она даже сможет догнать reiserfs на мелких файлах, т.е. на неё можно будет переводить файлопомойки, /tmp и /home. Будем ждать когда окончательно её допилят

NCQ лишь оптимизирует _порядок_выполнения_ команд чтения-записи, ext2/3/4/* как тормозили на мелких файлах, так и будут тормозить преимущественно из-за metadata overhead, особенно при фрагментации, особенно ext4, собственно поэтому для неё и делают дефрагментатор

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

>>> Какие-то там проценты...

Там уже речь про разы идёт, если бы про проценты.

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

>Друг, а ты ничего не перепутал? Это ext3 так тормозит на больших файлах, даже к гадалке ходить не надо. Это всем известно.

Не перепутал. Несколько месяцев /home был на XFS.

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

>С какими-такими большими файлами, если FAT32 файлы больше 2ГБ не поддерживает?

То что в скобках написано относится к XFS

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

> очень существенную прибавку скорости даёт

главное места!!!

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

>ext3 очень печалит, когда я вхожу в каталоги типа /usr/share/doc

для отмонтированного раздела
tune2fs -O +dir_index /dev/раздел
и
e2fsck -Df /dev/раздел

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

Ты наверное в параллельной Вселенной живёшь, в нашей Вселенной ext3 тормозит на больших файлах, а XFS нет.

timur_dav ☆☆☆☆☆
()
Ответ на: комментарий от dmit8815

> что другие ФС точно упали бы

"упали" или "упали бы" - это две разные вещи одна проверенная, а другая во сне приснилась

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

>как выбор ОС? =)

Хуже. ОС я выбрал легко и никогда не сомневался. Всегда знал, что в данный момент для меня лучше - такая-то ОС, для моего товарища - такая-то. А вот с выбором FS до сих пор не определился. У каждой свои достоинства и недостатки. Сейчас вокруг меня (буквально, т.е. в комнате): штук 10 reiserfs, штуки 4 xfs, 2 штуки ext3, три NTFS и штук 8 VFAT в виде флешек разного калибра :) Ну, кроме того, конечно, iso9660, udf и прочая :D

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

>Соклько не менял ФС - ни разу не заметил прироста скорости.

Я видел, при чём изменения в обе стороны :D Яуже упоминал, что рабочие каталоги Gentoo на XFS - это просто похоронная процессия :) Вот /home - там да, разница по скорости фиг заметна. /usr - в принципе, тоже.

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

> Не-а... Ни в какое сравнение не идёт.

У меня после апдейта до 2.6.24 стали быстрее то ли дисковые операции, то ли фс (подозреваю, что там или NCQ как-то более аккуратно используют, или шедулеры ввода-вывода потвикали).

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

dir_index - для быстрого поиска, при перечислении всего содержимого каталога от этой особенности никакого толку

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

>У меня после апдейта до 2.6.24 стали быстрее то ли дисковые операции, то ли фс (подозреваю, что там или NCQ как-то более аккуратно используют, или шедулеры ввода-вывода потвикали).

Я бы сказал, что оно _восстановилось_.

Когда в ~2.6.18 (не ручаюсь) появился CFQ, то система стала просто летать :) Потом, версия за версией, нагрузка на процессор при высоком IO стала расти... И только на ~2.6.23 снова упала до старого уровня. Сейчас - хорошо всё, шустро. 2.6.24 не щупал пока.

KRoN73 ★★★★★
()

>Разрабатывается программа для преобразования ext3 в ext4, но она пока не вошла в e2fsprogs.

Кто нибудь подробности знает ???

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

Я помню. Еще заметил жуткие тормоза при своппинге при включенном NCQ. Но я давно сидел на 2.6.23 (федора 8), и именно после установки 2.6.24 из апдейтов заметил улучшение.

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

> Можно использовать ReiserFS на / и ext3 на /home

у меня -- наоборот. Корень должно увидеть ядро любой обрезанности (например от RHEL) и он очень редко меняется, поэтому там почти нечему сбоить, а в /home всегда полно мелких файлов, которые постоянно меняются

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

>ext3 очень печалит, когда я вхожу в каталоги типа /usr/share/doc или /var/lib/dpkg/info и /usr/lib

индекс на каталоги поставь.

tune2fs тебе в руки.

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

>ещё один... ты хоть знаешь (по сути) что это такое и для чего?

Оно просто работает, и весьма быстро ! Проверь сам !
Вот что такое dir_index:

$mkdir /tmp/000
$cd /tmp/000
$for (( i=0; i < 30000; i++ )); do touch ${i}; done
$ time (ls -1 | wc -l)
30000

real 0m0.222s
user 0m0.181s
sys 0m0.035s

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

>Оно просто работает, и весьма быстро ! Проверь сам ! Вот что такое dir_index:

>$for (( i=0; i < 30000; i++ )); do touch ${i}; done

каким образом это вяжется с

>ext3 очень печалит, когда я вхожу в каталоги типа /usr/share/doc или /var/lib/dpkg/info и /usr/lib

т.е. c вызовом readdir? учи матчасть.

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

>$for (( i=0; i < 30000; i++ )); do touch ${i}; done

>ls -1 по твоему не readdir() ?

каким макаром "touch" == "ls -1" ?

>может ее тебе для начала подучить ?

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

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

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

давай ты еще раз прочитаешь мое первое письмо ? в нем:
1) я создаю 30000 файлов
2) я показываю что операция чтения из каталога с 30000 файлов через ls -1 очень быстрая

убедительно ???

xtron
()

Странные вы какие то. У меня линукс стоит на fat разделе дома - не жалуюсь. Бысто, стабильно, ПОНЯТНО. И из венды видно разделы.

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

И к тому же некорректный пример, т.к. файлы могут быть и не созданы на диске в момент окончания работы скрипта, а могут быть в дисковом кеше. Вообщем, как всегда: без sync'a, очередная ГСМщина

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

создай без dir_index (для сравнения), перед ls - sync и сброс буферов - тогда и приводи цифры, иначе это сферическая фигня

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

> Странные вы какие то. У меня линукс стоит на fat разделе дома - не жалуюсь. Бысто, стабильно, ПОНЯТНО. И из венды видно разделы.

На umsdos? Ничего себе "быстро" и "понятно".. Насчет стабильности тоже есть сомнения.

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

> убедительно ???

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

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

>И к тому же некорректный пример, т.к. файлы могут быть и не созданы на диске в момент окончания работы скрипта, а могут быть в дисковом кеше. Вообщем, как всегда: без sync'a, очередная ГСМщина

Прости но это клиника. причем тут вообще sync ? :D sync отвечает за синхронизацию кеша системы с накопителем. в данном же случае ls -1 в любом случае выдает все данные:

$ time (ls -1 | wc -l) 30000

Цифра 30000 не о чем не говорит ? Не говорит ли она о том что ls -1 увидела 30000 файлов ???

xtron
()

ходил по сылке:
"My almost-4-year-old daughter offered to help me fix the last ext4 bug I was working on"
ужос

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

Ну забыл добавить: sync + сброс буферов, + нет сравнения без dir_index, так что этот результат "показателен" непонятно относительно чего, + в режиме data=journal возможны трюки с обходом обязательной записи перед чтением

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

Эспешали фо ю:

# cd /root/000/
#for (( i=0; i < 30000; i++ )); do touch ${i}; done
#reboot

# cd /root/000/
# time (ls -1 | wc -l)
30000

real 0m0.601s
user 0m0.188s
sys 0m0.040s


Время чтения хоть и отличаеться слегка поскольку ничерта не прокешированно но все равно это никак нельзя назвать тормозами

xtron
()

ext4 - костыль, Линус говорит что ее не стоит воспринимать серьезно.

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

>reboot

ну зачем же так сурово, если можно просто sync && echo 3 > /proc/sys/vm/drop_caches ;-D

>Время чтения хоть и отличаеться слегка поскольку ничерта не прокешированно но все равно это никак нельзя назвать тормозами

_теста без dir_index нет_, так что это время непонятно куда вставлять и перед кем хвастаться =)

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

> Хуже XFS только fat. Ненадёжная и тормозная (в том числе при работе с большими файлама) фс.

Подтверждаю! Поставил XFS ради сравнения с reiserfs на raid5 массив из 4-х 15 тысячников - это просто тихий ужас. При загрузке виртуальной машины (образ 3-4 Гб) загружаемая система (win2k pro) впадает при загрузке несколько раз в ступор секунды на три-четыре (останавливается бегущая линейка) - консоль при этом показывает обращение к диску... Снес нафиг, поставил reiserfs - все грузится плавно и влет

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

>И работать надо не с одной директорией, а с деревом хотя бы одного уровня.

например ?

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

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

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

> за счет чего ext4 работает быстрее , чем ext3 ?

1) EXTENTS,
2) журнал по-быстрее по идее.

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

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

Не пошел бы ты к Райзеру?

anonymous
()

ReiserFS моё всьо :) Для обычного десктопа лучше нет (имхо?).

troorl ★★
()

К сожалению единственная неущербная FS для linux это XFS, но код ее достаточно сложен, что бы его не понимали пионеры типа Теодора Тсо и писали костыли ext2/ext3. Будем надеятся btrfs в обозримом будущем достигнет зрелости что бы стать fs N1 для linux.

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

провел у себя на виртуальной машине тест

df (после mke2fs): /dev/hdb1 2064168 3072 1956244 1%

ext3 defaults
df: /dev/hdb1 2064168 3508 1955808 1%
time ls -1:
real 0.364s
user 0.040s
sys 0.080s

ext3 dir_index
df: /dev/hdb1 2064168 3512 1955804 1%
time ls -1:
real 0.366s
user 0.030s
sys 0.080s

никакого "ускорения" и быть не может по определению, т.к. dir_index ускоряет только поиск _отдельных элементов_ из множества, а не readdir, тем более требует накладных расходов (cpu,hdd) на своё содержание

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

/proc/sys/vm/drop_caches - хозяйке на заметку

# mkdir /root/000/
# cd /root/000/
#for (( i=0; i < 30000; i++ )); do touch ${i}; done
#reboot
# cd /root/000/
# time (ls -1 | wc -l)


Вместо reboot в ядрах 2.6 можно делать :
# echo 1 > /proc/sys/vm/drop_caches

без сброса кеша у меня в 10 раз быстрее.

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

>К сожалению единственная неущербная FS для linux это XFS, но код ее достаточно сложен, что бы его не понимали пионеры типа Теодора Тсо и писали костыли ext2/ext3.

А интервью то с Eric Sandeen :-)

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