ИМХО такого нет в природе.

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

davl для ext2/3 у меня почему-то упал, хотя я для него специально подготовил образ ext3.

Но даже если оно работает, это только для ext2.

попробуй напиши, хуже не будет. Вот только кто пользоваться будет? Фргментация в линукс оч небольшая, все ей пренебригают. И правильно делают - на скорость работы мало влияет))

Если активно пользоваться торрентами, то фрагментация через полгода будь здоров, спасает только родной дефрагментатор XFS

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

Как активный пользователь торрентов хочу сказать, что это чересчур категоричное заявление. Если торрент-клиент сразу занимает место под будущий файл, фрагментация минимальна.

У каждого свой опыт в этом деле, особенно если потом удалять ненужное и на его место качать новое.

>особенно если потом удалять ненужное и на его место качать новое

У меня ситуация такая: терабайт кинематографа, каждый день что-то удаляется, что-то качается, полтора года, ext4, ktorrent либо aria2, фрагментации практически нет. Но, разумеется, в других условиях может быть другая картина.
А вот диск с музыкой довольно сильно фрагментирован, хотя в основном не с торрентов и не особо часто меняется содержимое. ХЗ почему.

попробуй напиши, хуже не будет. Вот только кто пользоваться будет?

Я буду. Опять-таки, если самому писать, оно готово будет только через года два, а мне сейчас уже хотелось.

Фргментация в линукс оч небольшая, все ей пренебригают.

Пока у меня не было данных, полученных лично, я тоже верил в этот миф. Фрагментация больше зависит от типа фс и драйвера. В ядре linux много разных файловых систем.

на скорость работы мало влияет))

Я задумался о фрагментации только из-за того что программа для бекапа подозрительно медленно (3 Мб/сек) читала файлы. Так что мой опыт говорит — влияет. В повседневной работе? После трех месяцев и полутора десятка мелких обновлений (debian testing) и 15 гигов скачанных торрентов нетбук стал грузиться две минуты вместо 50 секунд. В повседневной работе тоже заметно.

> занимает место под будущий файл, фрагментация минимальна.

Transmission не занимает.
Deluge занимает. но делает это дольше чем качает спасибо ext3

>Transmission не занимает.

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

https://trac.transmissionbt.com/wiki/ConfigurationParameters
preallocation    0 = Off, 1 = Fast, 2 = Full (slower but reduces disk fragmentation)

Насколько я понял из поиска в google и ответов в этой теме, программ, подходящих мне по функционалу, нет. По крайней мере в свободном доступе.

Отмечаю тему как решенную.

Мандрива, reiserfs 900Gb /home. Вот уже года 3 как не форматировал хомяка. Активный торрентист. Может просто ФС сменить? А то, что у кого-то медленно копируется, это хорошо, могло 12309 быть :)

davl да - капризная штука
раньше работал нормально - но сейчас сегфолтится сходу
кстати - для davl модуль подгрузить не забыл?

кстати - для davl модуль подгрузить не забыл?

Забыл, ибо не нашёл. А зачем там вообще модуль? Насколько я понял, там cdavl, которая через e2fslibs читает из блочного устройства, и графическая оболочка, gdavl. Модуль тут без надобности. Мы о модуле ядра говорим, да?

Оно как сегфолтнулось, так сразу отбило желание с ним разбираться дальше. К тому же у меня ext4 только на /boot, а с jfs davl не работает, поэтому чинить смысла нет.

без модуля ты нихера не заведёшь davl

без модуля ты нихера не заведёшь davl

Ладно.

А у JFS, оказывается, не реализован FIEMAP.

dumb FIEMAP for JFS

Тупая реализация через внутренний цикл по блокам. Это не так быстро, как при использовании структур экстентов jfs, зато теперь на каждый файл не надо вызывать ioctl тысячи, а то и сотни тысяч раз.

diff -ur linux-2.6.38-rc7-orig/fs/jfs/file.c linux-2.6.38-rc7/fs/jfs/file.c
--- linux-2.6.38-rc7-orig/fs/jfs/file.c	2011-03-01 21:55:12.000000000 +0000
+++ linux-2.6.38-rc7/fs/jfs/file.c	2011-03-07 11:04:54.413758941 +0000
@@ -133,6 +133,7 @@
 #ifdef CONFIG_JFS_POSIX_ACL
 	.check_acl	= jfs_check_acl,
 #endif
+	.fiemap		= jfs_fiemap,
 };
 
 const struct file_operations jfs_file_operations = {
diff -ur linux-2.6.38-rc7-orig/fs/jfs/jfs_inode.c linux-2.6.38-rc7/fs/jfs/jfs_inode.c
--- linux-2.6.38-rc7-orig/fs/jfs/jfs_inode.c	2011-03-01 21:55:12.000000000 +0000
+++ linux-2.6.38-rc7/fs/jfs/jfs_inode.c	2011-03-07 11:11:26.572759038 +0000
@@ -18,6 +18,7 @@
 
 #include <linux/fs.h>
 #include <linux/quotaops.h>
+#include <linux/fiemap.h>
 #include "jfs_incore.h"
 #include "jfs_inode.h"
 #include "jfs_filsys.h"
@@ -164,3 +165,10 @@
 fail:
 	return ERR_PTR(rc);
 }
+
+int jfs_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
+	       u64 start, u64 len)
+{
+	return generic_block_fiemap(inode, fieinfo, start, len,
+				    jfs_get_block);
+}
diff -ur linux-2.6.38-rc7-orig/fs/jfs/jfs_inode.h linux-2.6.38-rc7/fs/jfs/jfs_inode.h
--- linux-2.6.38-rc7-orig/fs/jfs/jfs_inode.h	2011-03-01 21:55:12.000000000 +0000
+++ linux-2.6.38-rc7/fs/jfs/jfs_inode.h	2011-03-07 11:07:33.113759241 +0000
@@ -41,6 +41,8 @@
 extern void jfs_set_inode_flags(struct inode *);
 extern int jfs_get_block(struct inode *, sector_t, struct buffer_head *, int);
 extern int jfs_setattr(struct dentry *, struct iattr *);
+extern int jfs_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
+		      u64 start, u64 len);
 
 extern const struct address_space_operations jfs_aops;
 extern const struct inode_operations jfs_dir_inode_operations;

>Если торрент-клиент сразу занимает место под будущий файл, фрагментация минимальна.

Угу. Если потом этот файл не удалять и не перемещать на другой раздел :)

>фрагментации практически нет

А как оцениваешь? А то сама ext4 много чего сказать может :D
http://img695.imageshack.us/img695/2885/imag0018to.jpg

706 тыс. фразментированных файлов из 1629 тыс. - это для неё только 1,5% ;)

Ты неправильно интерпретируешь цифры

<inodes used>/<inodes free>

То же самое можно посомтреть с помощью: df -i

А, понял, тут — ошибся. Но, всё равно, вопрос оценки уровня фрагментации очень неоднозначный. Эту тему на ЛОРе уже не раз поднимали. Если у нас 100 файлов и один из них порезан на 100 частей — это уровень фрагментации 1% или 50%? :)

это называется ппц

Фрагментация считается хитро: (число фрагментированных файлов + число фрагментированных директорий)/(число использованных inode). Хитрость в том, что файлы, у которых длина больше «blocks per group», не считаются фрагментированными. И не важно, на сколько кусков они порезаны.

Сомневающимся: apt-get source e2fsprogs и чтение исходников. Занимает 20 минут.

Это означает 1% файлов фрагментированно/1% non-contiguous

ext2/ext3/ext4 - это хорошо. А как быть с reiserfs?

А как быть с reiserfs?

Что-то я не заметил, чтобы fsck.reiserfs что-то говорил о фрагментации. Да и слова frag в reiserfsprogs-3.6.21 не встречается. А раз так, можно считать степень фрагментации по каким угодно своим формулам.

>Это означает 1% файлов фрагментированно

Что вреднее для ФС, когда один файл bp 100 порезан на 100 частей и «фрагментация один процент» или когда десять файлов порезаны на две части и «фрагментация 10%»? ;)

>А раз так, можно считать степень фрагментации по каким угодно своим формулам.

Угу. Вот в примере выше /var у меня имеет фрагментацию в 1.5%. fragck.pl говорит, что фрагментация этого раздела - 1.3%

Для раздела закачек на XFS этот же fragck.pl говорит о фрагментации в 27%. А данные xfs_db говорят о фрагментации в 97%... (однако, пора дефраг запускать)

Как кто хочет, так и считает... ;)

однако, пора дефраг запускать

блин, когда же будет дефраг для jfs и reiserfs?

Что вреднее для ФС (...) ?

ФС это просто структура данных, ей всё равно. А вот для меня вреднее когда у файла есть мелкие куски. То есть если файл состоит из кусков 2000 10000 10000 2000 2000 - это еще ничего. Плохо когда 2000 1 1 1 2 1 1 10000. Большинство метрик фрагментации этого не учитывают.

> Что вреднее для ФС

ФС всё равно.

> Плохо когда 2000 1 1 1 2 1 1 10000. Большинство метрик фрагментации этого не учитывают.

При размерах кластера порядка десятка секторов (а то и больше) - уже всё равно. Про SSD молчу.

> При размерах кластера порядка десятка секторов (а то и больше) - уже всё равно.

У меня размер кластера (блока) — 4096 байт. Размер сектора — 4096 байт. Эти цифры нельзя изменить. + Медленный диск, 4200 RPM. Линейная скорость чтения — 40 Мб/с в начале и 22 Мб/с в конце диска. Чтение фрагментированных файлов — 2 Мб/сек. Так что не все равно.

Про SSD молчу.

Сказки здесь неуместны. У SSD тоже есть задержка на чтение, она меньше, но не нулевая.

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

И что? По-твоему, секвентальное чтение двух блоков сильно отстаёт от чтения двух радномных блоков? Это не так.

> При размерах кластера порядка десятка секторов (а то и больше) - уже всё равно.

У меня размер кластера (блока) — 4096 байт. Размер сектора — 4096 байт.

У тебя размер кластера равен одному сектору. ССЗБ

Эти цифры нельзя изменить.

Выбери другую ФС, в чём проблема?

+ Медленный диск, 4200 RPM. Линейная скорость чтения — 40 Мб/с в начале и 22 Мб/с в конце диска. Чтение фрагментированных файлов — 2 Мб/сек. Так что не все равно.

Могу посочувствовать в выборе неподходящей ФС.

>При размерах кластера порядка десятка секторов (а то и больше) - уже всё равно.

А «дефраг мувом» по прежнему повышает быстродействие пожилой системы в разы :)

Про SSD молчу.

А зря. Там много своей специфики. Например, при записи фрагментация может снизить скорость просто чудовищно, так, что SSD станет медленнее HDD :)

>И что? По-твоему, секвентальное чтение двух блоков сильно отстаёт от чтения двух радномных блоков? Это не так.

Время выбора нужного блока там ненулевое. Оно, конечно, пренепрежимо со временем среднего сика на HDD, но, тем не менее.

Основная проблема с фрагментацией на SSD - на записи. Сколько там сегодня типичные размеры блока на флеш? 256..512кбайт? Ты пишешь туда 4кбайт блок и ради этого блока считывается 256кбайт, стирается блок и пишутся изменённые на 4кбайт 256кбайт. При линейной записи большого массива данных - пофиг, так как запись будет идти целыми блоками. А вот при фрагментации — увы.

И это не теория, а суровая практика, с которой сталкиваются, например, при записи видео на SD-карточки. На моём 550D, если ФС на карточке дефрагментирована, то честного Class 6 хватает с заметным запасом. Стоит появиться хотя бы небольшому уровню фрагментации — всё, запись видео обламывается, не хватает скорости записи…

>Могу посочувствовать в выборе неподходящей ФС.

А какая «подходящая»? :) Скорость чтения падает на порядок при высоком уровне фрагментации и на ext4, и на reiser4, и на xfs, и на ntfs, и на fat32 ;) Неужели в какой-то ФС придумали чудо, нарушающее законы природы?

> А какая «подходящая»?

Та, где можно использовать кластеры размером не тольк в 4киб.

> Сколько там сегодня типичные размеры блока на флеш? 256..512кбайт? Ты пишешь туда 4кбайт блок и ради этого блока считывается 256кбайт, стирается блок и пишутся изменённые на 4кбайт 256кбайт.

Меньше, думаю, около 128киб.

Используйте подходящие ФС и контроллеры, с поддержкой TRIM & «правильной» аллокацией & flush'ем.

> Например, при записи фрагментация может снизить скорость просто чудовищно, так, что SSD станет медленнее HDD :)

1) Владелец ФС с размером блока в 4киб и диском с размерами блока в 4киб жаловался на проблемы с чтением.

2) В подовляющем большинстве преминений файлы чаще читаются, чем пишутся

>Та, где можно использовать кластеры размером не тольк в 4киб.

А какие нужно? Меньше — падение производительности. Больше - пропадает место в хвостах.

>Меньше, думаю, около 128киб.

Это у мелких объёмов было, 128-256. Полагаю, что размер блока должен по мере роста объёмов тоже немного расти.

В любом случае, даже 128кбайт - это очень много для записи одиночного 4кб сектора :)

Используйте подходящие ФС и контроллеры, с поддержкой TRIM & «правильной» аллокацией & flush'ем.

Как это спасёт от физической необходимости перечитывать и перезаписывать весь блок при малой его модификации? Это конструктивная особенность flash — стирание блоками.

>В подовляющем большинстве преминений файлы чаще читаются, чем пишутся

Что не отменяет проблем при записи, там где она важнее.

> Что не отменяет проблем при записи, там где она важнее.

Выбирай подходящие носители для задач.

> Как это спасёт от физической необходимости перечитывать и перезаписывать весь блок при малой его модификации? Это конструктивная особенность flash — стирание блоками.

1) В HDD так же стирается всё блоками. В новых - блоки уже 4киб

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

Основные проблемы возникают, когда люди используют неподходящие (и часто - не совсем совместимые) вещи.

>Выбирай подходящие носители для задач.

Сегодня на рынке есть компактные твёрдотельные альтернативы флешу? Пруф!

>В новых - блоки уже 4киб

4/4 и 4/128 - есть разница? :)

Последовательность можно изменить - чтение, запись модифицированных даных в новый блок и стирание старого

Хватит, в среднем, только на 4/128..4/256 = 1,5-3% имеющегося места. Потом начнётся наша проблема.

Кэширование записи и слияние запросов никто не отменял.

Так кеш-то не спасёт. Данные всё равно нужно записать на уже частично занятый блок. Ну отложил ты эту запись, отложил следующую... Всё равно записывать придётся рано или поздно, а сгруппировать запись не получится, так как полностью чистые блоки уже кончились :)