LINUX.ORG.RU

Время проверки ФС ext4 в разы меньше ext3/2

 , ,


0

0

Theodore Ts'o в своём online-дневнике поделился информацией о скорости проверки диска, отформатированного в ext4. Согласно его измерениям, шестимесячный том ext4 FS размером в 128 GB проверяется за 63 секунды, тогда как те же самые данные, скопированные на свежеотформатированный раздел ext3, проверялись 425 секунд, т.е. почти в 7 раз медленней.

Фёдор не обратил внимание на интересную деталь из лога проверки: 779726 inodes used (9.30%), 1 non-contiguous inode (0.0%), т.е. либо он копировал на ext4 файлы, никогда не удаляя старые, либо в ext4 наконец-то работает online-дефрагментатор, что не может не радовать — теперь в Линуксе есть две файловые системы, которые позволяют ускорить доступ к лежащим на них данным. [От автора новости: осталось дождаться, когда кто-то напишет prefetcher и исправит дефрагментатор, чтобы тот учитывал порядок чтения файлов при запуске системы].

>>> Подробности

★★★★★

Проверено: Shaman007 ()

>шестимесячный ext4 FS

шестинедельный, ага.

А вообще странные результаты, если это правдда, то наверное сам драйвер оптимизировали, т.е. заслуга кода, а не структуры файловой системы.

sdio ★★★★★
()

Теперь пусть поставит туда torrent-клиент на те же 6 месяцев. Результаты фрагментации, думаю, неприятно удивят.

TuxR ★★★★
()

preload - Adaptive readahead daemon

anonymous
()

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

Дык есть же [prefetcher]. Применяется в RHEL. Не уверен насчёт особого ускорения, правда. А дефрагментатору не обязательно думать на счёт "порядка чтения файлов при запуске системы", это практически не сыграет роли.

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

use proper filesystems, Luke и забудь про фрагментацию.

А дырявые (sparsed)-файлы помогают сильно экономить место на тех же торрентах.

AngryElf ★★★★★
()

Я чет не в курсах... А ext4 уже стабильна? Ее можно использовать для хранения критически важных данных? И есть ли преимущества в скорости по сравнению с ext3?

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

> Дык есть же [prefetcher]. Применяется в RHEL. Не уверен насчёт особого ускорения, правда. А дефрагментатору не обязательно думать на счёт "порядка чтения файлов при запуске системы", это практически не сыграет роли.

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

И того: если при загрузке последовательно читать файлы от начала диска -- то в теории будет быстрее.

А на практике...

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

Вобщем -- как повезет.

anonymous
()

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

А вторая — это какая?

WFrag ★★★★
()

Reiser4 победит.

Чего только не делают люди, лишь бы не писать плагины к Reiser4.

Camel ★★★★★
()

jfs пока хлопот не доставил.

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

Данные на Ext3FS фрагментируется, причём весьма сильно, в зависимости от числа операций удаления/записи файлов. Так что встроенный дефрагментатор в новой системе Ext4FS будет весьма кстати.

Для сравнения: на UFS2 фрагментированности данных почти нет (максимум 5%); fsck допускает выполнение в фоновом режиме.

iZEN ★★★★★
()

>non-contiguous inode

>ускорить доступ к лежащим на них данным

а вот это, вроде бы, к фрагментации именно файлов не имеет никакого отношения, т.к. место для инодов выделено всегда

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

> Я чет не в курсах... А ext4 уже стабильна? Ее можно использовать для хранения критически важных данных? И есть ли преимущества в скорости по сравнению с ext3?

Присоединяюсь к вопросу. И какие дистры нынче при установке умеют ext4?

Bohtvaroh ★★★★
()

Ух ты, birdie вернулся.

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

>Присоединяюсь к вопросу. И какие дистры нынче при установке умеют ext4?

Fedora умеет уже с 9 только надо написать iamanext3developer при установке.

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

> И какие дистры нынче при установке умеют ext4?

Gentoo.

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

>Для сравнения: на UFS2 фрагментированности данных почти нет (максимум 5%); fsck допускает выполнение в фоновом режиме.

Скорость только её не радует и остальные фичи, которые идут в нагрузку тоже :-(

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

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

Что особенно актуально для SSD! Особенно важны еженедельные прогоны дефрагментатора на таких накопителях.

> А на практике...

Вы всё ещё дефрагментируете? Ну для проверки диска на пригодность, наверное полезно...

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

ext[234]fs sucks, and have been always suck ! xfs is only FS for Linux that is relay reliable, however ZFS will be never ported to linux, thats sucks too !

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

> Fedora умеет уже с 9 только надо написать iamanext3developer при установке.

Вообще-то в финальной версии достаточно написать "ext4".

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

> Где-то месяц-другой назад они меняли on-disk формат, о какой стабильности вы мечтаете?

Вообще-то его уже еще перед 2.6.26 стабилизировали, несколько месяцев назад были последние измненения.

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

> А вообще странные результаты, если это правдда, то наверное сам драйвер оптимизировали, т.е. заслуга кода, а не структуры файловой системы.

А теперь внимание, правильный ответ. Я спросил tytso в блоге об этом и он объяснил, что это просто бага в fsck, из-за которой фрагменты не считались :)) Реальная фрагментация за 6 недель использования составила 2.2%.

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

anonymous
()

Про ext3 в ближайшее время нужно забывать, как про затянувшееся недоразумение. Будем надеяться, что ext4 не станет таким же недоразумением (во многом, а, может, и в основном, благодаря стараниям разработчиков lustre)

Led ★★★☆☆
()

ext4 ещё надо допилить. Вот я себе поставил, чисто поглядеть на работу. В-общем, производительность сильно радует, чисто субъективно, она побыстрее reiserfs v3, а уж в сравнении с ext3 так вообще ракета. Мне уже ext4 нравится, но заметил глюк: при копировании на раздел ext4 иногда вылазит ошибка типа не хватает места. Например, копирую кучу небольших файлов. Вся куча весит 40 Гб. На разделе ext4 свободного места 60 Гб, а всё равно вылазит ошибка...

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

> >Вы всё ещё дефрагментируете?

> А ты купил себе SSD? Ну и ЛОХ

А вы все еще пользуетесь FAT? В нормальных ФС фрагментация на скорости чтения/записи практически не сказывается.

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

>А вы все еще пользуетесь FAT? В нормальных ФС фрагментация на скорости чтения/записи практически не сказывается.

Гы-гы, это ж какие это "нормальные фс"?

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

>Гы-гы, это ж какие это "нормальные фс"?

AstralFS, вестимо:)

Led ★★★☆☆
()

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

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

Ви будете смеяться, но добрый-старый reiser, например. Когда мерил боней++ - разница между вусмерть зафрагментированным разделом и свежеотформатированным вполне укладывалась в погрешность измерений. Правда, "нормальность" этой ФС на ЛОРе вечно ставится под сомнение ;)

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

> Ви будете смеяться, но добрый-старый reiser, например. Когда мерил боней++ - разница между вусмерть зафрагментированным разделом и свежеотформатированным вполне укладывалась в погрешность измерений.

Рейзер из HDD делает SSD?! Иначе не понятно, как постоянное позиционирование головок диска может уложиться в погрешность измерений...

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

> ods у нее другой. как раз в расчете на схожную("срач на диске") ситуацию и "остразаточенный".

Интересно тогда, почему универсальный userspace-дефрагментатор shake был написан именно для райзера, и по тестам разработчика дефрагментация с его помощью дает большой прирост производительности?

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

как раз - именно ПОЭТОМУ. для других fs - чтонить "эдакое" написать - сложнее.

p.s. а "тесты разработчика" - неаргумент. хотя, если не злоупотреблять(особенно на сервере) - эффет ощутимый. но жиже "ручного" аналога.

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