XFS и фрагментация

И что? Лаги заметны стали?

xfs_fsr -v /dev/sdXX

xfs_fsr -v /dev/sdXX

После xfs_fsr показывает, что фрагментация ~0. Оно и понятно. Я про то, что в процессе работы оно таки дико фрагментируется.

И что? Лаги заметны стали?

Вход в каталог стал заметен по времени и скорость копировани упала. Но меня не практический аспект интересует (сделать дефраг - не проблема), а теоретическию Получается-то, что xfs ничем не лучше остальных => пригодность xfs к торрентам и низкая её фрагментация - миф?

Делай преаллокейшн.

Под торрентами, наверное, все фрагментироваться будет. Зато у XFS есть онлайн-дефрагментатор, поэтому не миф.

Делай преаллокейшн.

Как?

Под торрентами, наверное, все фрагментироваться будет. Зато у XFS есть онлайн-дефрагментатор, поэтому не миф.

Не, онлайн-дефрагментатор, конечно, добро, но, получается, это и есть весь плюс xfs? Грустно, как-то...

ext4, е-мое! Попробуй, понравится! Рекомендую опции монтирования nosuid,nodev,noatime,barrier=1,data=writeback

зависит от торрент-клиента, например про rtorrent можно почитать тут:

http://libtorrent.rakshasa.no/ticket/460

"Latest commit contains some code for this... Can't test it since MacOSX doesn't support posix_fallocate. To try it out, configure with '--with-posix-fallocate' and set 'system.file_allocate.set = yes'. When starting large torrents, it should hang for a while allocating the files on disk. " - 5 месяцев назад.

Народу нравится: "the change just hit the optware distro. Awesome work mate, the difference is really *vast*! "

> Я про то, что в процессе работы оно таки дико фрагментируется.

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

Если хочешь - можешь обучить торрент клиента создавать пустой файл и затем писать уже в него.

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

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

> Пишешь один с середины самого большого куска свободного места и второй середины следующего куска свободного места

Объём полностью свободен.

Файлов больше двух. Неизвестно сколько

Размеры их неизвестны, некоторые большие, некоторые маленькие. Неизвестно какие которые.

Мы - файловая система. Наши действия?

> Мы - файловая система. Наши действия?

Гм... Повторим-с.

1. есть 1 кусок места размером N.

2. пришёл запрос на создание файла 1

3. начинаем создавать с середины нашего самого большого куска. получается 2 свободных куска - перед файлом размером N/2 и после файла размером тоже N/2, при этом тот что после постепенно заполняется данными файла.

4. пришёл запрос на создание файла 2

5. начинаем создавать с середины нашего самого большого куска. получается 3 свободных куска - перед файлом 2 размером N/4 и между файлом 2 и файлом 1 размером тоже N/4 (постепенно заполняется данными файла 2). и после файла 1, размером N/2 (постепенно заполняется данными файла 1)

6. пришёл запрос на создание файла 3 начинаем создавать с середины нашего самого большого куска. получается 4 свободных куска - перед файлом 2 размером N/4 и между файлом 2 и файлом 1 размером тоже N/4 (постепенно заполняется данными файла 2). и между файлом 1 и файлом 3, размером N/4 (постепенно заполняется данными файла 1), и после файла 3, размером N/4 (постепенно заполняется данными файла 3).

И так далее. Если представить этот довольно упрощённый алгоритм, получим возможность создать 3 файла и нефрагментированных до размера примерно N/4.

Первые пять файлов оказались очень маленькими.

Следующие два - но размеру на треть файловой системы каждый.

Хорошо, я немного упростил, но если эта часть понятна :), можно и усложнить. Во первых, следует начинать не с середины а с начала свободного пространства при условии что перед куском нет открытого на запись файла, таким образом файл 1 полезно записывать с начала и мы получим N/3, но это не суть. Суть в том что размер файлов никак не коррелирует с размером файловой системы, и соответственно при приведённом алгоритме найдётся такое разумно большое N чтобы вместить большое количество файлов размерами M1, M2, ... Mk без дефрагментации.

... Например. Можем разработать модель, например для N в 2Тб и k=2, M1=1Гб, M2=1кб, на глаз можно прикинуть что разместится штук 500 файлов вообще без дефрагментации. (в любой произвольный момент жизни ФС), а в целом фрагментация будет более чем разумной - 1-3 фрагмента.

> но размеру на треть файловой системы каждый.

Ну и конечно, в реальности никто не делает файлов 'на треть ФС', самые большие файлы что встречаются в торрентах - ~50гб, что есть примерно 1/40 от нормальной 2Тб фс под торренты :) и, кроме того, ясно что даже десять фрагментов в таком файле совсем не беда.

xfs при записи резервирует место, т.е. ты пишешь 8Кб данных, а xfs откусывает для этого файла 4Мб в расчете, что ты продолжишь запись. Если нет то резерв освобождается.

зависит от торрент-клиента, например про rtorrent можно почитать тут:

О! Спасибо! Будем поглядеть...

Берёшь два больших файла ...

Ну, на сколько я понял, delayed allocation как раз может тут помочь.

Если хочешь - можешь обучить торрент клиента создавать пустой файл и затем писать уже в него.

Вариант, кторрент у меня так и делал, но к ФС это отношения не имеет.

xfs при записи резервирует место, т.е. ты пишешь 8Кб данных, а xfs откусывает для этого файла 4Мб в расчете, что ты продолжишь запись. Если нет то резерв освобождается.

Вот как раз этого поведения я что-то и не наблюдаю. По крайней мере из коробки.

Имхо это все-таки больше зависит не от ФС, а от торрент-клиента.
В свое время юзал Azureus/Vuze, так он по умолчанию в начале скачивания все файлы создавал и забивал нулями до нужного размера. Как с этим в других клиентах — не в курсе, давно уже с торрентами дела не имею.

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


Я юзаю ext4, с дефолтными настройками (в убунте) и у меня и торренты, и дцц с локалки (и качается достаточно прилично всего). И музыка, и что-то я не замечаю пока что проблем. Может позже вылезут, хз. В XFS была очень суровая ынтырпрайз фича которая работала только в IRIX - это гарантированная скорость чтения (это очень важно для станций визуализации и для реалтайм монтажа видео) но насколько я понял она ж00стко привязана к ириксу и в ляликс ее никто не портировал, увы. И еще кое какие суровые фичи. Т.е. на ляликсе какой то кастрат от великой и ужасной оригинальной XFS.

и да, все мною виденные торрент клиенты место резервируют заранее под скачанный файл. (раньше юзал азуреус, сейчас трансмишн, но пробовал много что, хотя понравились только эти два клиента, а трансмишн не жрет памяти как азуреус, да и последний после того как его купило vuze - или как там, каким то жутким УГ стал ваще)

Вот. А дцц клиент EiskaltDC. (ну у меня в локалке по дцц раздают, никуда не децо, зато 100мегабит и прилично так контента)

и да, все мною виденные торрент клиенты место резервируют заранее под скачанный файл.

А как ты это определил? А то есть два варианта:

1. Программа создаёт пустой файл нужного размера.
2. Программа создаёт пустой файл и забивает его нулями до нужного размера.

И в том, и в другом случае ls будет показывать одинаковый полный размер, но в первом случае на большинстве современных ФС место на диске будет заниматься только по мере записи реальных данных. Против фрагментации помогает только второй вариант, а первый ей очень способствует =).

И просто для примера:

$ printf x | dd of=verybigfile bs=1 seek=4617948836650
1+0 записей считано
1+0 записей написано
 скопирован 1 байт (1 B), 5,9854e-05 c, 16,7 kB/c

$ ls -lh verybigfile 
-rw-rw-r--. 1 ivan ivan 4,2T Ноя 12 09:12 verybigfile

>Вроде как фрагментация там будет сильно меньше ввиду delayed allocation

Фрагментация там сильно меньше из-за xfs_fsr: http://balancer.endofinternet.net/munin/home/home/xfs_frag-week.png

Ставишь в ночной cron "nice -n +19 ionice -c3 xfs_fsr /dev/balvg/downloads2" - и имеешь профит :)

>но, получается, это и есть весь плюс xfs?

Во-первых, это killer feature. У конкурентов пока под Linux ничего аналогичного нет. Так что уже за одно это её можно выбрать. Не только этим она хороша. Ещё топовая производительность на чтении.

>Программа создаёт пустой файл нужного размера.
>Программа создаёт пустой файл и забивает его нулями до нужного размера.

Я наверное отстал от жизни, либо мы с тобой разные вещества принимаем.
Или я что-то пропустил и программы научились создавать "пустые файлы нужного размера" каким то новым модным загадочным способом, когда физически существуя на диске ФС начинает работать в режиме телепата читая мысли торрент клиента и твои, узнавая что файл то на самом деле не НАСТОЯЩИЙ а фейк, и используя это место под свои ч00рные цели ?

Похоже на какое то безумие, если между нами. Я уже в матрице что-ли ? Или нули это такая сакральная цифра которая что-то меняет ? (какая в жопу разница, НУЛИ ТАМ ВНУТРИ ИЛИ НЕТ ??)

Или я что-то пропустил и программы научились создавать «пустые файлы нужного размера»

Ну начнём с главного - союз развалился...

Я же показал как с помощью dd создать пустой файл размером в несколько терабайт, который реально на диске будет занимать несколько байт. Такие файлы называются «разреженными» (sparse).

s/пустой/почти пустой/

http://en.wikipedia.org/wiki/Sparse_file

...

Ну а про то, что Союз развалился, выше уже сказали.

> Как?

ktorrent к примеру умеет преаллокейтить и на XFS и с помощью posix_fallocate (ext4).

>Ну а про то, что Союз развалился, выше уже сказали.

Жесть. Союза жалко.
А вы фрагментацию окромя как на хэшировании вообще замечаете ? Мне кажется это надуманная проблема совершенно, при современных винтах с очередями команд, дисковым кэшем огромным, умными контроллерами и огромным количеством процессов на типичном сервере или загруженной воркстейшн.
Заметно наверное только при хэшировании и видеоредактировании нелинейном реалтайм. (я не замечаю лично вообще, качать больше чем смогу посмотреть сам + подруга не пробовал, может в этом проблема).

Во-первых, это killer feature. У конкурентов пока под Linux ничего аналогичного нет. Так что уже за одно это её можно выбрать.

Для Ext3 нету дефрагментатора разве?

В vuze есть галочка - использовать метод размещения файлов характерный для xfs.

>Для Ext3 нету дефрагментатора разве?

Есть, mv называется.

>А вы фрагментацию окромя как на хэшировании вообще замечаете ?

На банальном копировании очень хорошо заметно, когда трансфер падает с 60Мбайт/сек до 15 :)

Для /usr или /opt время запуска программы может увеличиваться в несколько раз, даже до 10 раз в самых запущенных случаях.

...

Правда, для этих разделов я в итоге ext4 выбрал, а дефраг делаю традиционно - mv'ом :) Благо, они небольшие, это не сотни гиг видео...

>> Для Ext3 нету дефрагментатора разве?

Есть, mv называется.

mv уже стал перемещать данные файла, когда источник и назначение - на одной файловой системе?

Описанный алгоритм размещения файлов напоминает тот, который использовался ещё системой RT11 при записи на пятидюймовые ГМД. Давно уже существуют более интересные и более полезные алгоритмы, которые не предотвращают фрагментацию, а значительно снижают потери производительности и нагрузку на носитель, связанные с фрагментацией. Например, такая древность, как HPFS.

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

И ещё современная UFS2. Но в Linux её не осилили почему-то, а вместо неё взяли и сделали Ext4 пока без дефрагментатора.

Кстати, B-trees в UFS2 по описанию сильно смахивают на B-trees в HPFS.

Ну я описал первый что пришел в голову просто чтобы показать что существуют такие алгоритмы, которые позволяют хранить данные без фрагментации. Понятно что сики в разные части hdd различаются, скорость доступа может отличаться в 2 раза между секторами в начале и конце hdd, всё это можно учесть и сделать более грамотный алгоритм. И конечно реальные fs сделаны по другому, неплохо было бы найти описание кстати.

Если говорить про реальные FS

По ext2 нашел: http://e2fsprogs.sourceforge.net/ext2intro.html см physical structure.

When writing data to a file, Ext2fs preallocates up to 8 adjacent blocks when allocating a new block. Preallocation hit rates are around 75% even on very full filesystems. This preallocation achieves good write performances under heavy load. It also allows contiguous blocks to be allocated to files, thus it speeds up the future sequential reads.

Потом народ борется с проблемами подхода: http://marc.info/?l=linux-ext4&m=111471578328685&w=2

и http://lwn.net/Articles/144006/

Отсюда следует что в ext3 любой файл размером больше block_group будет фрагментирован. Для 276Gb фс оказалось 2236 групп, размер одной получается 126Mb, чтоб посмотреть есть ext3grep.

Про XFS:

http://en.wikipedia.org/wiki/XFS#Allocation_groups

Та же фигня, только с extents, которые есть и в такой древности как HPFS :)

А B-tree как я понимаю относятся больше к метаданным и их поиску, а также к поиску блоков а вовсе не к их allocation.(?)

> Ext2fs preallocates up to 8 adjacent blocks when allocating a new block

Нечто в этом роде я и имел в виду. Такой способ предраспределения используется в HPFS. Фрагментация есть, но она ограничена. Дефрагментаторов для HPFS не было и не планировалось, никто не жаловался (особенно на фоне FAT, современной с HPFS, и даже на фоне JFS, в которой дефрагментатор есть).

B-trees - это структуры в директориях, с размещением данных не связаны. Упомянуты в связи с UFS2, в которой они также используются.

>> Есть, mv называется.

> mv уже стал перемещать данные файла, когда источник и назначение - на одной файловой системе?

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

Изучайте субкультуру.

Я кагбэ в курсе. Худеть надо, товарищ. Я имел в виду, что семантика mv ничего такого не подразумевает.

>ext4, е-мое! Попробуй, понравится! Рекомендую опции монтирования nosuid,nodev,noatime,barrier=1,data=writeback

,nodiratime

>Я имел в виду, что семантика mv ничего такого не подразумевает.

См. ещё раз моё сообщение.

> См. ещё раз моё сообщение.

Могу предложить вам то же самое.

> mv уже стал перемещать данные файла, когда источник и назначение - на одной файловой системе?

Кроме ссылок на субкультуру есть что сказать по существу? Обсуждаются не мемы о дефрагментации, а она сама, родимая. Без второго раздела mv вообще мимо кассы, нечего поминать его всуе.

>Кроме ссылок на субкультуру есть что сказать по существу?

mv на другой раздел является работающим средством борьбы с фрагментацией. Ещё вопросы?