LINUX.ORG.RU
Форум — Talks  

[ВНЕЗАПНО] А знаете ли вы, что онлайн-дефрагментатор для ext4 уже работает?

 


0

1

Я вот не знал до сегодняшнего дня. А оказывается, что все необходимые изменения для работы дефрагментатора были приняты в основное ядро ещё в июне прошлого года и успели войти в релиз 2.6.31. Утилиты e4defrag ещё нет в текущем стабильном релизе e2fsprogs (на данный момент - 1.41.9), но она есть в git'e.

[2010.01.12 19:14:27] root@homeserver ~/e2fsprogs
# ./misc/e4defrag -c ~ftp/torrent/completed/5920
<Fragmented files>                             now/best          ratio
1. /srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/TV Tuner/AverMedia A310 XP32/AVerA310USB.sys
                                                 3/1            28.57%
2. /srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/Videocard/nVidia/nvwcpsv.hl_
                                                 4/1            27.27%
3. /srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/Touchpad/WinWDF/x86/SynTP.bmp
                                                 2/1            25.00%
4. /srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/LAN/IA32/b57nd60x.cat
                                                 5/1            23.08%
5. /srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/Launch Manager/Setup.x64
                                                 3/1            20.00%

 Total/best extents                             2886/1475
 Fragmentation ratio                            0.84%
 Fragmentation score                            6.70
 [0-30 no problem: 31-55 a little bit fragmented: 55- needs defrag]
 This directory(/home/ftp/torrent/completed/5920) does not need defragmentation.
 Done.

[2010.01.12 19:16:34] root@homeserver ~/e2fsprogs
# ./misc/e4defrag ~ftp/torrent/completed/5920
ext4 defragmentation for directory(/home/ftp/torrent/completed/5920)
[3/1634]/srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/BIOS и все, что с ним связано..url:     100%    [ OK ]
[4/1634]/srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/Образы скрытых разделов.url:    100%    [ OK ]
... вырезано ...
        Success:                        [ 1475/1634 ]
        Failure:                        [ 159/1634 ]

[2010.01.12 19:16:34] root@homeserver ~/e2fsprogs
# ./misc/e4defrag -c ~ftp/torrent/completed/5920
<Fragmented files>                             now/best          ratio
1. /srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/Videocard/ATI/Driver/data1.cab
                                                 2/1             0.19%
2. /srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/Audiocard/Vista/RTKVHDA.sys
                                                 2/1             0.19%
3. /srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/Audiocard/Vista/RtkAPO.dll
                                                 2/1             0.19%
4. /srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/Audiocard/WDM/MicCal.exe
                                                 2/1             0.19%
5. /srv/ftp/torrent/completed/5920/Drivers_www.acerfans.ru/Wi-Fi/32-bit/w29n50.sys
                                                 2/1             0.18%

 Total/best extents                             1551/1475
 Fragmentation ratio                            0.05%
 Fragmentation score                            0.36
 [0-30 no problem: 31-55 a little bit fragmented: 55- needs defrag]
 This directory(/home/ftp/torrent/completed/5920) does not need defragmentation.
 Done.

Что интересно - я на торрентокачалке не нашёл ни одного сильно фрагментированного файла. Видимо при наличии свободного пространства ext4 действительно умеет хорошо распределять свободное место.

P.S. Да, я спалился, а это - драйвера для ноутбука Acer под б-гомерский windows 8).

P.P.S. В этот тред призывается KRoN73.

Deleted
← pekmop1024 и другие владельцы IPS и *VA мониторов
skynet!!! →
  1 2 3
Ответ на: комментарий от iZEN

> Линупсятники всё ещё дефрагментируют

Дык только ж недавно начали, да и то не все :-)

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

>Так так. У вас нет дефрагментаторов? До сих пор?!

Им дефрагментаторы не нужны. У них есть аутотренинг «я не пук^W^W^W ZFS не фрагментируется» :)

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

Значит будем ждать дефрагментатора свободного места :)

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

>Так так. У вас нет дефрагментаторов? До сих пор?!

Представь себе, он не нужен для UFS2 и ZFS, так как эти ФС изначально проектировались с учётом дикой фрагментации на загруженных серверах. И чтобы избежать этой дикой фрагментации и НЕ использовать дефрагментатор вообще, нашли выход: записывать блоки данных в группы «цилиндров», использовать переменный размер блоков. И хранить метаинформацию не в начале логического пространства носителя, как это делается в FAT, NTFS, UFS1, Etx2/3/4, а распределённо — в тех же группах цилиндров, что и данные, описываемые ими; в ZFS вообще в этом случае всё волшебно (включая сжатие).

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

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

Блин, так что ж ты молчал-то? Надо ребятам из линукса идею объяснить, они в ext5 тоже сделают, чтобы было так круто!

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

В ext4 уже кое-что сделали по мотивам UFS2. Глядишь, через пять лет появится что-то похожее на ZFS.

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

>хранить метаинформацию не в начале логического пространства носителя, как это делается в FAT, NTFS, UFS1, Etx2/3/4

Пеши исчо!

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

> записывать блоки данных в группы «цилиндров»
Типо как экстенты в ext4?

И хранить метаинформацию не в начале логического пространства носителя

У ext2/3/4 метаинформация как раз не сосредоточена в начале диска, а размазана по всему объёму (группы). Суперблок дублируется много раз. (меня это спасло после того как винт начал сыпаться).
Даже у FAT хранится ещё одна копия FAT в конце диска AFAIR.

Nao ★★★★★
() 
nao e2fsprogs  # misc/e4defrag /store/hda2.img.000.gz.3
ext4 defragmentation for /store/hda2.img.000.gz.3
Segmentation fault

Пусть пока пилят :)

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

> Типо как экстенты в ext4?

Не типо, а да — как экстенты, но ещё лучше: помимо переменного размера блока используется пространство неполностью занятых блоков. Поэтому на UFS2 фрагментация никогда не превышает 3-5% в самых тяжёлых случаях использования.

У ext2/3/4 метаинформация как раз не сосредоточена в начале диска, а размазана по всему объёму (группы).


Только в ext4. Я же сказал, что её сделали по мотивам UFS2.

Суперблок дублируется много раз.


Это не важно. У ext2/3 всего одна группа индесксных дескрипторов и одна группа блоков данных для всего раздела, физически находящихся в начале адресуемого пространства раздела. На UFS2 копии суперблока, собственные inodes физически находятся в каждой группе цилиндров. Ещё никому не удавалось восстановить данные после повреждения корневого inodes на ext2/3, а UFS2 в этой ситуации неубиваема (разве что разрушились ВНЕЗАПНО все группы цилиндров).

Даже у FAT хранится ещё одна копия FAT в конце диска AFAIR.


У FAT32 нет ограничений на размещение копий критических данных. Копии FAT могут размещаться в произвольном месте раздела. ФС FAT12/16/32 хорошо поддаются восстановлению.

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

>Поэтому на UFS2 фрагментация никогда не превышает 3-5% в самых тяжёлых случаях использования.

Ох уж эта iZEN'овская физика :)

В самых тяжёлых случаях фрагментация приблизится к 100% в любом случае. Или файл не удастся разместить вообще.

Запиши на гиговый раздел 250 тыс. файлов по 4 килобайта. Удали все чётные файлы. Запиши 62,5 тыс. файлов по 8 кбайт. Уже получишь фрагментацию в 33 или 50% (смотря как считать). Удали все файлы по 4 кб и запиши ещё 62,5 тыс. файлов по 8. Получишь 100% фрагментацю. Ни одного нефрагментированного файла.

Если с геометрией туго, вот пример:
Файлы по 4кбайт (обозначем буквами):
abcdefghijklmno...

Удаляем чётные:
a_c_e_g_i_k_m_o_....

Записываем по 8кб (обозначаем цифрами):
a1c1e2g2i3k3m4o4...

Удаляем 4кб:
_1_1_2_2_3_3_4_4 - уже в этот момент фрагментация стала равна 100%.

Вписываем 8кб:
5151626273738484...

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

KRoN73 ★★★★★
()

Вот делалось оно бы как-нибудь само, по мере надобности, а то так, что-то запускать, сколько-то ждать...

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

Вот делалось оно бы как-нибудь само, по мере надобности, а то так, что-то запускать, сколько-то ждать... 

echo 'ionice -c 3 e4defrag /' >/etc/cron.weekly/e4defrag

Дёшево и сердито =).

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

>что б не дрочить винт за зря? :)

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

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

так-то оно так, но на десктопе по-моему и раз в неделю за глаза,а сервак - это уже да :) хотя это зависит конечно от нагрузки

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

>так-то оно так, но на десктопе по-моему и раз в неделю за глаза

Если /usr какой-нить - то да. /home - уже много частностей вылезает. А p2p - разделы - я уже ссылку кидал, как там выходит :) - http://balancer.endofinternet.net/munin/home/home/xfs_frag-month.png

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

а что за софтинка такое рисует?

$ eix -e munin
[I] net-analyzer/munin
     Available versions:  ~1.3.3 ~1.3.3-r1 ~1.3.3-r2 ~1.3.4 1.3.4-r1 1.3.4-r2 {doc irc minimal munin-apache munin-dhcp munin-irc munin-squid munin-surfboard mysql postgres ssl}
     Installed versions:  1.3.4-r2(21:24:53 14.08.2009)(doc irc mysql postgres ssl -minimal)
     Homepage:            http://munin.sourceforge.net
     Description:         Munin Server Monitoring Tool

Вот оно в общем виде: http://balancer.endofinternet.net/munin/ (домашняя машина, с которой сейчас пишу) или: http://admin.airbase.ru/munin/ (мой сервер)

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

Размер блока UFS2 по умолчанию 16 кбайт.

Поехали.

Запиши на гиговый раздел 250 тыс. файлов по 4 килобайта.


4 файла в блоке. Фрагментация — 0%

Удали все чётные файлы.


2 файла в блоке. Фрагментация — 0%

Запиши 62,5 тыс. файлов по 8 кбайт.


В блоках будет: 2 файла по 4 кбайт и 1 файл по 8 кбайт. Фрагментация — 0%

Уже получишь фрагментацию в 33 или 50% (смотря как считать).


4.2

Удали все файлы по 4 кб


В блоках будет: 1 файл по 8 кбайт и свободное пространство 8 кбайт. Фрагментация — 0%

и запиши ещё 62,5 тыс. файлов по 8.


В блоках будет: 2 файл по 8 кбайт. Фрагментация — 0%

Получишь 100% фрагментацю. Ни одного нефрагментированного файла.


4.2

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

Будем считать, что для UFS2 ты неудачно подобрал размер файлов, чтобы её дико зафрагментировать. Проехали.

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


UFS2 использует фрагменты для записывания голов новых файлов в незаполненные хвосты уже записанных блоков. По умолчанию для блока используется формула 8:1 == 8 фрагментов на блок.

Если файл размером 12 кбайт запишется в блок (16 кбайт), то оставшиеся 4 кбайта блока будут использованы для записи данных нового файла. И все блоки данных локализуются в одной логической зоне адресации на разделе — в «группе цилиндов» или в смежных группах цилиндров, если файл очень большой. Таким образом решается часть проблемы фрагментации в UFS2. Использование переменного размера блоков для файлов очень большого размера решает вторую часть проблемы фрагментации в UFS2.

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

Это не важно. У ext2/3 всего одна группа индесксных дескрипторов и одна группа блоков данных для всего раздела, физически находящихся в начале адресуемого пространства раздела.

Требую забанить или отрезать сотню скора у изена за такоё лютое, бешеное и наглое 4.2

Смотри сюда: http://e2fsprogs.sourceforge.net/ext2intro.html начинай читать с «Physical Structure». Всё ещё веришь что у ext2 одна группа индексных дескрипторов и блоков данных?

А вот для ext3: http://books.google.ru/books?id=B5NC5-UfMMwC&pg=PA482&lpg=PA482&dq=ext3+on-disk+structure&source=bl&ots=nSLZD71H-q&sig=5P2a3uCe4sM7COS9zyp5_TP0JeM&hl=ru&ei=wAROS7OIDpyOnQOX8pzADQ&sa=X&oi=book_result&ct=result&resnum=6&ved=0CCgQ6AEwBQ#v=onepage&q=ext3%20on-disk%20structure&f=false

На UFS2 копии суперблока, собственные inodes физически находятся в каждой группе цилиндров.

Прикинь, у ext[2-4] также (про 1 ничего не знаю), только s/цилиндров//

Ещё никому не удавалось восстановить данные после повреждения корневого inodes на ext2/3,

У ext нет «корневого inodes», у каждой группы свой список, также как и у ufs2. Если ты имел ввиду суперблок, то он дублируется в каждой группе, также как на ufs2.

а UFS2 в этой ситуации неубиваема (разве что разрушились ВНЕЗАПНО все группы цилиндров).

Если у тебя убъётся таблица inodes например в первой группе цилиндров то данные в этой группе у тебя считай грохнулись(точнее данные то живы, но теперь хрен кто разберёт где кто), а в остальных группах невредимы.
Ну и в ext так же :)

Насчёт фрагментации:
Вот домашняя машина на Gentoo:

Fs    fs-type  size   used     frag%   
/home ext4     594G   587G     2.4%
/usr  ext3      12G   8,3G     5.1%
/var  ext3     6,1G   1,4G     2.9%
/home - торренты и всё такое. перекочевала из ext3 гдето пол-года тому назад, раньше была ext3
/usr - куча исходников в /usr/src (привычка там хранить) и портежи
/var - измученная компиляциями в /var/tmp
Никаких дефрагов ранее не использовал, по /home только прошёлся самую малость (каталоги-монстры downloads, music и anime даже не успел продефрагментить)

Теперь сервачок на FreeBSD:

Fs    fs-type  size   used     frag%   
/usr  ufs2      14G    11G     5.2%
основная нагрузка на эту партицию - кеш сквида. У остальных партиций фрагментация незначительная.

Этим я хочу сказать что ufs2 не какая-то супер-пупер фс на которой невозможна фрагментации. Линейка фс ext справляется с фрагментацией на уровне. Лучше или хуже - судить не мне, но однозначно что ext* ну никак не сливает ufs2 в этом.

Про ZFS ничего не скажу, т.к. не в теме. Могу сказать что её более корректно будет сравнивать с btrfs когда она выйдет.

Вобщем прекращай пердеть в лужи. Популярность FreeBSD ты такими методами не заработаешь. Из-за тебя у многих на ЛОРе к FreeBSD складывается отрицательное отношение. На словах Наполеон, а на деле один пустой пиздёж и 4.2.

Исправляйся или вали с моего ЛОРа.

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

> UFS2 использует фрагменты для записывания голов новых файлов в незаполненные хвосты уже записанных блоков

Где-то я это уже видел. tail-packing на рейзере?

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

>В блоках будет: 2 файла по 4 кбайт и 1 файл по 8 кбайт. Фрагментация — 0%

Вот этот момент поясни.

1. Было: abcd.
2. Удалили, стало a_c_
3. Записали - стало a1c1

Как у тебя стало возможным, скажем, ac11? Система сделала мув при записи? Так это тормоза будут те ещё. Или я что-то упускаю?

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

> Смотри сюда: http://e2fsprogs.sourceforge.net/ext2intro.html начинай читать с «Physical Structure». Всё ещё веришь что у ext2 одна группа индексных дескрипторов и блоков данных?

Ну ладно. Ты победил.

Этим я хочу сказать что ufs2 не какая-то супер-пупер фс на которой невозможна фрагментации. Линейка фс ext справляется с фрагментацией на уровне. Лучше или хуже - судить не мне, но однозначно что ext* ну никак не сливает ufs2 в этом.


Да нету у ext2/3 блоков с переменным размером и задействование фрагментов недоконца занятых блоков. А это — ключ к низкой фрагментации. В этом-то они сливают UFS2.

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

> Вот этот момент поясни.

1. Было: abcd.

2. Удалили, стало a_c_

3. Записали - стало a1c1


Как у тебя стало возможным, скажем, ac11? Система сделала мув при записи? Так это тормоза будут те ещё. Или я что-то упускаю?


Стало: a1c1 — единички == фрагменты файла, который 8 кбайт, уместились в фрагменты блока. (В одном 16 кбайтном блоке: 8 фрагментов по 2 кбайта).

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

>Стало: a1c1 — единички == фрагменты файла, который 8 кбайт, уместились в фрагменты блока

Файл занимает один блок, но он физически порезан на два фрагмента.

В одном 16 кбайтном блоке


Хорошо, возьми пример не с 4 и 8кБ файлами, а с 4 и 8Мбайтными.

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

Теперь сервачок на FreeBSD:

Чем смотреть фрагментацию ФС во FreeBSD? А то я тут решил снова провести эксперимент с целью сажания iZEN'а в лужу...

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

> Чем смотреть фрагментацию ФС во FreeBSD?

Запусти fsck на разделе с UFS2. Он покажет степень фрагментирванности в %.

А то я тут решил снова провести эксперимент с целью сажания iZEN'а в лужу...


Ну, дафай, дафай.

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

> Файл занимает один блок, но он физически порезан на два фрагмента.

Думаю, да. Извини, hex-дамп файловой системы не смотрел. Но ведь всё равно в один блок уложилось, а транзакции ОС с накопителем работают на уровне целых блоков, а не фрагментов, так что какого-то изменения в производительности I/O не будет.

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

Запусти fsck на разделе с UFS2. Он покажет степень фрагментирванности в %.

Он явно что-то не то показывает. На тестовом стомегабайтном разделе он всегда выдавал 0%, хотя судя по хексдампу раздела - фрагментация была неслабая.

Ну, дафай, дафай.

А что? С RAID'ом же в прошлый раз вышло =).

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

>транзакции ОС с накопителем работают на уровне целых блоков, а не фрагментов

Какая разница, если этот блок приходится собирать с разных концов (физически) диска?

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

> Файл занимает один блок, но он физически порезан на два фрагмента.

Думаю, да. Извини, hex-дамп файловой системы не смотрел. Но ведь всё равно в один блок уложилось, а транзакции ОС с накопителем работают на уровне целых блоков, а не фрагментов, так что какого-то изменения в производительности I/O не будет.

В одном 16 кбайтном блоке


Хорошо, возьми пример не с 4 и 8кБ файлами, а с 4 и 8Мбайтными.


ОС автоматически увеличит размер блока в 16 раз, а незаполненный «хвост» оставит для других файлов.

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

>решил снова провести эксперимент с целью сажания iZEN'а в лужу...

Я что-то пропустил? Когда это iZEN из неё вылез?

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

> Он явно что-то не то показывает. На тестовом стомегабайтном разделе он всегда выдавал 0%,

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

хотя судя по хексдампу раздела - фрагментация была неслабая.


Ты смотрел фрагменты блоков одного файла? И в каком порядке они расположены?

С RAID'ом же в прошлый раз вышло =).


Что там вышло? Что RAID-2 сам по себе не обеспечивает целостность данных? Так это я уяснил.

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

> Какая разница, если этот блок приходится собирать с разных концов (физически) диска?

Блоки физически неделимы. Фрагменты блока «пристыкованы» друг к другу.

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

Изен, ты случайно в конфе freebsd@c.j.r под ником magistr не пишешь?

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

>Чем смотреть фрагментацию ФС во FreeBSD?
не забудь добавить ключик -n к fsck если будешь сканить смонтированную фс, а то будет плохо :)

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

Тогда одно из двух:
1. Блоки придётся двигать при записи новых файлов на раздел, что вызовет некислые тормоза.
2. Придётся пожертвовать значительной частью свободного пространства.

Что происходит в ufs2?
Можешь схематически изобразить ситуацию, описаную KRoN73?

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

> не забудь добавить ключик -n к fsck если будешь сканить смонтированную фс, а то будет плохо :)

А мужики-то и не знали!!

fsck UFS2 всегда работает на снапшоте. То есть возможна работа на смонтированной ФС. Специальный системный вызов к ОС приводит в соответствие ремонтные работы на живой файловой системе (как правило, при работе утилиты освобождается пространство от битых/недозаписанных файлов и увеличивается пространство на диске).

Всегда запускаю «fsck -y» на смонтированном разделе и не боюсь битых файлов. ;) После этой команды их просто нет.

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

Чудес не бывает. Бывает оптимизация свободного пространства не на уровне блоков, а их фрагментов. Данные с носителя читаются блоками, так что I/O не страдает.

UFS2, как написано, утилизирует пропускную способность интерфейсов накопителей на 95% — это лучше, чем у ZFS.

iZEN ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3
← pekmop1024 и другие владельцы IPS и *VA мониторов
Talks
skynet!!! →