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

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

И как это помогает в ситуации когда файл занимает больше одного блока?(какой максимальный размер блока, кстати?)

И как это помогает в ситуации когда файл занимает больше одного блока?

При любом раскладе «хвосты» выделенных блоков не остаются незаполненными.

(какой максимальный размер блока, кстати?)

man newfs(8)

-b block-size

The block size of the file system, in bytes. It must be a power of 2. The default size is 16384 bytes, and the smallest allowable size is 4096 bytes. The optimal block:fragment ratio is 8:1. Other ratios are possible, but are not recommended, and may produce poor results.

...

-d max-extent-size

The file system may choose to store large files using extents. This parameter specifies the largest extent size that may be used. It is presently limited to its default value which is 16 times the file system blocksize.

...

-f frag-size

The fragment size of the file system in bytes. It must be a power of two ranging in value between blocksize/8 and blocksize. The default is 2048 bytes.

# dd if=/dev/zero bs=1M count=1024 of=fs
# mdconfig -a -t vnode -f fs
# newfs -i 2048 -m 0 /dev/md0 #Чтобы иноды не закончились
# mkdir /mnt/1/
# mount /dev/md0 /mnt/1/
# cd /mnt/1
# for ((i=1;250000-$i;i=$i+1)); do dd if=/dev/urandom bs=4k count=1 of=$i; done &>/dev/null
# for ((i=2;250000-$i;i=$i+2)); do rm $i; done &>/dev/null
# for ((i=1;62500-$i;i=$i+1)); do dd if=/dev/urandom bs=8k count=1 of=z$i; echo $i/62500; done &>/dev/null
dd: z*: No space left on device
 ...
# df -hi /mnt/1/
Filesystem    Size    Used   Avail Capacity iused  ifree %iused  Mounted on
/dev/md0      890M    447M    443M    50%  143612 404162   26%   /mnt/1

Вот такая фигня получилась. Не пойму почему :) Рамер блока 16k

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

Да-да. И при чтении файла «a» в блоке «a1b1» нам тогда придётся прочитать в 4 раза больше, чем нужно... :) А при чтении файла «1» придётся ещё в середине чтения выполнять позиционирование головки винчестера. И ещё - я не уверен, что современные винты позволяют при чтении (в DMA-режиме) задавать последовательность чтения разных участков. В этом случае при чтении с винта придётся обработать на одно прерывание больше.

> И при чтении файла «a» в блоке «a1b1» нам тогда придётся прочитать в 4 раза больше, чем нужно... :) А при чтении файла «1» придётся ещё в середине чтения выполнять позиционирование головки винчестера. И ещё - я не уверен, что современные винты позволяют при чтении (в DMA-режиме) задавать последовательность чтения разных участков. В этом случае при чтении с винта придётся обработать на одно прерывание больше.

Неверно думаешь.

Транзакции дисковых операций над файлами производятся на уровне блоков ФС. Для чтения файла «1» будет прочитан весь блок «a1b1» в память, а в памяти из этого блока UFS2 склеит фрагменты для получения файла «1» и отбросит ненужные фрагменты.

Файл «a» прочитается из смежных блоков — головка накопителя вряд ли покинет их группу цилиндров.

Фрагменты блоков по отдельности не читаются. Данные читаются только поблочно.

> Не пойму почему

У FFS есть сильное ограничение на количество файлов в одном каталоге, после которого перестаёт хватать inode'ов на новые.

И есть ещё небольшая задержка (1-2 секунды) между удалением файлов и реальным освобождением их inode'ов на диске. В этом случае программы получают ENOSPC.

>Для чтения файла «1» будет прочитан весь блок «a1b1» в память

Вот-вот. И когда у нас «a»=1Гб, «b»=1Гб, «1»=2Гб, то при чтении блока «a» придётся вместо 1Гб читать 4Гб? :)

...

Я понимаю твой фанатизм, но голову-то (свою, не винчестера) включать нужно? :)

Файл «a» прочитается из смежных блоков — головка накопителя вряд ли покинет их группу цилиндров.

Я зря, что ли, второй раз предложил тебе перейти от килобайт к мегабайтам?

Вот-вот. И когда у нас «a»=1Гб, «b»=1Гб, «1»=2Гб, то при чтении блока «a» придётся вместо 1Гб читать 4Гб? :)

Сам понял какой бред сморозил? Какой у тебя 1ГБ файл будет в память ВЕСЬ читаться? Никакой и ни на какой ФС такого не будет. Будет плавный маппинг физических блоков файла в файловый буфер довольно-таки небольшого размера — в зависимости от жадности приложения, коорое читает файл. И на тачке с 512МБ ОЗУ файл 1ГБ, 4ГБ, 8ГБ и даже 128ГБ вполне себе будет обрабатываться, а не сваливать ОС в кору от нехватки оперативки и/или SWAP.

Я зря, что ли, второй раз предложил тебе перейти от килобайт к мегабайтам?

Какая разница? Главное хвост!

>У FFS есть сильное ограничение на количество файлов в одном каталоге, после которого перестаёт хватать inode'ов на новые.

Я вроде писал про UFS2. Ну если только ты имеешь ввиду что UFS2 наследует это ограничение от FFS?
Не думаю что проблемы была в этом, т.к. я половину файлов снёс. Т.е. как минимум был запас 250000/2 инодов в директории.

И есть ещё небольшая задержка (1-2 секунды) между удалением файлов и реальным освобождением их inode'ов на диске. В этом случае программы получают ENOSPC.

Нет, проблема точно не в этом. Я запустил процесс в фоне и он висел там минимум пару минут.

Кстати сами файлы всё же создавались, ошибка выдавалась именно при записи 8k в них. Сейчас уже не помню создались ли они размером 0 или 4k, посмотрю позже.

Насколько я понял, не фиксированный размер блока аналогичен по результатам с экстентами в ext4.
Зато у UFS2 нету dellayed allocations (который есть в ZFS и ext4) который тоже хорошо уменьшает фрагментацию.

>Какой у тебя 1ГБ файл будет в память ВЕСЬ читаться?

Зачем весь? Достаточно линейно читать при раздаче по p2p.

Ты разговор не уводи. Файл получается фрагментированным. Точка.

>> Какой у тебя 1ГБ файл будет в память ВЕСЬ читаться?

Зачем весь? Достаточно линейно читать при раздаче по p2p.

При раздаче по p2p читаются последовательности смежных блоков в файловый буфер. Далее идёт маппинг занимаемой ими памяти на память программы-агента p2p. Та уже нарезает из полученных последовательностей байтов одного файла пакеты данных со служебной информацией для протокола p2p в заголовках передаваемых данных. Программой, обслуживающей p2p-обмен, «чанки» передаются стеку TCP/UDP/IP, в котором происходит заворачивание их в протокол TCP или UDP. Далее вниз по стеку — в пакет IP. Далее в пакет MAC-уровня. И всё это отправляются по назначению сетевой подсистемой ОС на другие компы, где полученные пакеты «распаковываются» в обратном направлении и, в конечном счёте, данные, опять же, через буфер записи, записываются на диск.

Ты разговор не уводи. Файл получается фрагментированным. Точка.

У тебя в мозгу.

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

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

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

По этой ссылке неполностью представлена физическая структура Ext2.

Я пользовался вот этим источником: http://filesystems.nm.ru/other/ext2_arch.djvu
В связи с этим всё-таки смею предположить, что повреждение «таблицы дескрипторов групп» (аналог для NTFS — MFT), находящаяся в нулевой группе блоков ФС Ext2, полностью лишает доступа к остальной части ФС.

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

> Я пользовался вот этим источником: http://filesystems.nm.ru/other/ext2_arch.djvu

В связи с этим всё-таки смею предположить, что повреждение «таблицы дескрипторов групп» (аналог для NTFS — MFT), находящаяся в нулевой группе блоков ФС Ext2, полностью лишает доступа к остальной части ФС.

Из твоего же источника:
«Так же, как и для суперблока, операционная система создаёт резервные таблицы дескрипторов»

Прочитай хотя бы вторую (если считать с обложкой - третью) страницу своей книжки, а потом приходи на ЛОР бздить про ext2.

Да и в выводе dumpe2fs их отлично видно, они идут сразу после копии суперблока в группе.
Щас специально создал ext2 в файле, забил файлами и затёр первую группу ddом. После fsck все файлы из других групп выжили. Правда корневая инода (которая находилась в нулевой группе) померла и всё что было в корне сложилось в нумерованном виде в lost+found, но структура внутри тех директорий которые выжили сохранилась.

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

А что если вы говорите о разных вещах? Ну то есть слово одно используете, а концепции разные подразумеваете?

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

Когда блоки маленькие, скажем, 4 килобайта, время на подготовку чтения блока с диска (определение нужного места, подвод туда головки диска, ожидание, пока диск прокрутится до нужного положения) доминирует над временем собственно чтения. Соответственно, эффекты фрагментации могут проявляться в полный рост. Если, как вы предлагаете, начать рассматривать блоки размером в 1 ГБ (непрерывные последовательности базовых блоков, или экстенты), то для их прочтения время подготовки ввода-вывода будет много меньше выполнения собственно ввода-вывода. Так что даже если блоки в 1 ГБ одного файла будут чередоваться с блоками другого - фрагментация! - эффект от оной будет в пределах погрешности измерений.

Впрочем, в случае, когда чередуются блоки минимального размера, никто не заставляет читать их по-одному - ничто ведь не запрещает прочитать, скажем, 256 блоков по 4 килобайта непрерывно, а затем в памяти собрать чередующиеся 512К одного файла в непрерывный кусок. Некоторые ФС поступают именно таким образом.

В некоторых файловых системах (например, потомках BSD FFS) предусмотрена возможность деления блока на фиксированное количество частей меньшего размера - фрагментов, - и использования этих фрагментов для хранения хвостов файлов, не занимающих полного блока. Например, блок может быть размером 8К, и допускать разбиение его на 8 фрагментов по 1К. И фрагментацией может называться отношение количества свободных фрагментов (отражающее, хоть и не напрямую, количество блоков, поделенных на фраменты) к общему количеству блоков для данных в файловой системе. Понятно, что эта фрагментация (блоков на фрагменты) не будет иметь ничего общего с фрагментацией (отсутствием непрерывности и правильности порядка расположения блоков файла на диске), рассмотренной ранее. Однако это метрика, имеющая право на существование, и существующая, вне зависимости от того, как вы к ней относитесь, на протяжении более чем 25 лет.

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

>Но обе концепции имеют право на жизнь :-)

Право на жизнь имеет только та концепция, в которой при линейном чтении файла не требуется делать лишнего позиционирования головки и при котором при чтении файла размером в 1Гб через интерфейс будет передан именно 1Гб :)

> Право на жизнь имеет только та концепция, в которой при линейном чтении файла не требуется делать лишнего позиционирования головки и при котором при чтении файла размером в 1Гб через интерфейс будет передан именно 1Гб :)

Идеалист вы батенька ;-)

> Идеалист вы батенька ;-)

да ладно - вот придет SSD в каждый дом и сразу геморроя станет поменьше

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

Угу, нет головок - нечего позиционировать, нет блинов - нечего крутить. Такая тема для религиозных баталий пропадет :-)

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

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

Наивный. Можно подумать, что контроллёр SSD не знает про блоки. Почитайте форум ixbt по flash-носителям и узнайте, как люди изгаляются, чтобы подогнать размер кластера файловой системы (NTFS) под размер «блока» ячеек, с которыми работает контроллёр в режиме доступа с минимальной задержкой (за одно обращение). Это всё — ради того, чтобы уменьшить количество транзакций обращения контроллёра непосредственно к памяти и фактически уменьшить латентность флэш-накопителя для операционной системы, которая не знает о его внутреннем устройстве ничего.

При переходе от UFS1 к UFS2 отказались от кода FFS, учитывающего физическую геометрию винчестера и строящего политику размещения блоков на основе относительного расположения цилиндров, так как последние LBA-контроллёры выдавали космические параметры для принятой в ФС CHS-представления адресации носителя («255 головок» — нехило, да?).

Задача на будущее: разработать методику/политику работы с носителем таким образом, чтобы минимизировать служебный трафик между контроллёром и флэш. Сейчас это решается буферизацией ввода-вывода и расширением полосы пропускания интерфейсов, однако не отменяет дикую латентность флэш (особенно на MLC-ячейках). В идеале, латеность флэш должна быть такой же, как и у модулей ОЗУ.

я не сказал - не будет геморроя, я сказал - его будет меньше, разницу между подбором размера кластера и расположением данных на блинах жестких понимаешь?

я не сказал - не будет геморроя, я сказал - его будет меньше, разницу между подбором размера кластера и расположением данных на блинах жестких понимаешь?

А что там за разница? Подскажи.