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

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

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

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

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

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

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

Пеши исчо!

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

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

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

> Типо как экстенты в 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 хорошо поддаются восстановлению.

>Поэтому на 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...

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

Размер блока 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

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

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

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

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

Это не важно. У 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%

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

Fs    fs-type  size   used     frag%   
/usr  ufs2      14G    11G     5.2%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Было: abcd.

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

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

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

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

На рейзере и XFS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.filesystems.nm.ru/my/freebsd_fs.pdf

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

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

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

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

Таки наскоолько я понял из прочитаного, ситуация будет полностью аналогична описаной в http://www.linux.org.ru/jump-message.jsp?msgid=4431587&cid=4435490 Чудес не бывает даже в ufs2.

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

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

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

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

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

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

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

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-ячейках). В идеале, латеность флэш должна быть такой же, как и у модулей ОЗУ.

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

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

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