намекаю

… сектора «в одиночку не ходют», они «собиратся» в кластеры…

ЗЫ сам вопрос отчего возник? какую «доку» штудируешь?

… сектора «в одиночку не ходют», они «собиратся» в кластеры…

Ну так это еще хуже, не? Типа даже не 512 байт, а больше.

Читаю ман mke2fs. Там сказано:

mke2fs creates an inode for every bytes-per-inode bytes of space on the disk. The larger the bytes-per-inode ratio, the fewer nodes will be created. This value generally shouldn’t be smaller than the blocksize of the filesystem, since in that case more inodes would be made than can ever be used.

Что еще сильнее удивляет. Ведь размер блока обычно 4КиБ. Да и фиг с ним с 4КиБ, допустим я могу поставить минимум - 512 байт. Меньше ж не получится, сектор то 512.

Или это из-за какого-то редкого железа,где сектора меньше 512 байт?

У ext[234] не может быть логического размера сектора 512 байт. 1к - минимум.

Это сейчас Инода стала аж 256 байт, а раньше она была 128 байт.

физически размеры сектора бывают разные. 4к сектора достаточно распространенное явление.

У ext[234] не может быть логического размера сектора 512 байт. 1к - минимум.

Эээм.. Пруфы?

 cat /sys/class/block/sdX/queue/logical_block_size
512

Это сейчас Инода стала аж 256 байт, а раньше она была 128 байт. физически размеры сектора бывают разные. 4к сектора достаточно распространенное явление.

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

inode тоже не один в секторе/кластере… посмотри хоть эту иллюстрацию

inode тоже не один в секторе/кластере… посмотри хоть эту иллюстрацию

Видел эту иллюстрацию, но не совсем уверен, что правильно понимаю. То что указано - inode table - это таблица инод. Таблица инод - написано что это массив инод. Но меня путает вот что - где-то написано, что на каждые 16КиБ создаётся по иноде. А в этой схеме иноды находятся в массиве (т.е. как я понял сразу несколько инод) в группе блоков, т.е. не один инод на 16КиБ.

ЗЫ Или на каждые 16 КиБ создаётся по одной иноде в таблице одного блока?

в чём ты прав… я пришёл к мысли, что весьма туманно представляю себе внутреннее строение ext. и та иллюстрация слишком «общая», если вдуматься… н-да (

Тут надо смотреть структуру фс , возможно иноды выделяются и хранятся как-то по особому

Есть еще такая вещь как упаковка хвостов файлов в блок для уменьшения места

Можно попробовать создать несколько файлов с атрибутами чтоб занять иноду и посмотреть содержимое секторов диска. Но это задача не для простых смертных

Ну как я понял, на каждую группу блоков создаётся таблица инод, где хранятся иноды (но это не точно, я еще выясню), т.е. раз они рядом, то могут хранится и в одном секторе (не точно), при этом одна таблица инод хранится в одной группе блоков (судя по иллюстрации), а количество блоков зависит от размера ФС и блоков. В итоге получается, что на каждую группу блоков выделяется n-ное количество инод.

Возможно я не прав, поправьте, пожалуйста

Тут есть нюанс, у xfs иноды динамические, поэтому упаковывать их постоянно накладно

Ну да, речь пока про статическое выделение инод. Но я тут посмотрел tune2fs -l /dev/sdXX и нашел примечательные строки

Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512

Значит где-то выставляется количество инод на группу. Т.е. возможно я прав

I verified this experimentally, resizing from 1G to 10G and looking at tune2fs /dev/X | grep Inode. The inode count went from 64K to about 640K. I believe it’s a natural consequence of Unix filesystems which use «block groups». The partition is divided into block groups, each of which has their own inode table. When you extend the filesystem, you’re adding new block groups.

На случай, если кому интересно - https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Block_Group_Descriptors

/sys/class/block/sdX/queue/logical_block_size - это размер блока у блочного девайса. В понятиях ext[234] это физический размер блока.

логический размера блока ext[234] можно посмотреть в tune2fs

Пруфы - man mke2fs "-b"

У ext[234] не может быть логического размера сектора 512 байт. 1к - минимум.

Я думал вы говорили про сектор, а вы про блок.

Глянул, действительно, минимальный размер блока для ext4 - 1КиБ. Хотя, как я понимаю, это программное ограничение - xfs вроде может в 512, ну или по крайней мере мог.

Inode’ы хранятся на диске подряд, т.е. в 512-байтном секторе будет два 256-байтных inode’a. Да, держать по одному inode’у на сектор может быть выгоднее с точки зрения производительности. А с точки зрения оверхэда структур ФС типично менее выгодно. Поэтому обычно забота о производительности, сроке службы диска и батарее ограничивается флагами вроде noatime и иже с ним. А те, для кого это существенно, могут добавить ключик при форматировании для увеличения размера inode’а. В xfs v5, емнип, по дефолту 512.

Спасибо

Еще такой вопрос. В английской литературе меня немного путает, что всё называют блоками -

A sector, in contrast, is a small block whose size is usually determined by the underlying hardware

Поправьте меня, если я неправильно понимаю.

1. physical block - это сектор
2. logical block - это блоки, которыми оперирует ядро. И относится это к понятию, что «ядро работает с накопителями с помощью блоков данных фиксированной длины».
3. block - это уже в основном про блоки файловой системы.

block

Это зависит от контекста, может быть что угодно из упомянутого. Для избежания неопределённости иногда ещё пишут «fs block».

logical block

Это блоки, которыми происходит адресация при обращении к блочному устройству. Оно же logical sector. Минимальный кусок, который ОС может попросить устройство прочитать/записать.

physical block

Это блоки, которыми устройство на самом деле читает/записывает данные. Оно же physical sector. Может отличаться в большую сторону от размера логического сектора. Старые ОС, которые не в курсе, что сектор может быть больше 512 байт, продолжат работать, пусть и не так эффективно. Новые ОС будут стараться делать I/O блоками по 4k. Т.е. разница между физическим и логическим сектором нужна для совместимости. Когда вымрут ОС, которые не умеют большие сектора на HDD, логический сектор тоже сделают 4k.

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

Можно ли попросить вас проверить правильность этого текста?

накопители – это блочные устройства и ядро работает с ними с помощью блоков данных фиксированной длины. Так вот, сектора являются минимальной физической единицей и называются физическими блоками, а их размер можно глянуть в файле (cat /sys/class/block/sdc/queue/physical_block_size). А те самые блоки фиксированной длины, которыми оперирует ядро – это логические блоки (cat /sys/class/block/sdc/queue/logical_block_size). Но, кроме этого, также и у файловых систем существует понятие блоков. Как выяснили раньше, секторам, в которых хранится файл, не обязательно находится рядом. В системе бывают тысячи файлов, какие-то растут, какие-то удаляются, появляется промежуток между секторами файла. Происходит так называемая фрагментация диска. И жесткому диску для прочтения одного файла приходится совершать больше движений, от чего падает производительность. Когда таких файлов много – это беда. И если каждый сектор – это 512 байт, жесткому диску придётся несладко, прыгая между кучей разделённых секторов. А вот если объединять сектора в небольшие группы, называемые блоками, допустим по 8 секторов – т.е. 4 кибибайта, то диску будет проще. Да и дело не только в этом – файловой системе легче работать с блоками. Допустим, если секторов по 512 байт на больших дисках получается огромное количество, то файловой системе может не хватить адресов, в итоге не получится создать файловую систему и файл большого объёма. Но вот объединив сектора в блоки, пусть хоть по 64 кибибайта, получится во много раз увеличить допустимый размер диска и файла. Это как с блокнотом, давая номер каждой клеточке блокнота у вас просто перестанет помещаться номер клетки в вашей таблице. Зато нумеруя не клетки, а страницы, вы сможете использовать куда больше клеток.

Но, при этом, у блоков есть свои недостатки. Файловая система хранит информацию в блоках, а значит 1 файл – минимум 1 блок. Если предположить, что средний размер одного блока – 4096 байт, то для хранения однобайтного файла вы потратите 4096 байт. Если у вас в системе большинство файлов – мелкие – то уйма места не будет использоваться. В таких случаях лучше указывать размер блока минимальным – для ext4 это 1К. В любом случае, куча мелких файлов – большой напряг для диска. Но сейчас, в основном, файлы довольно большие, поэтому особо места вы не потеряете, если будете использовать 4 кибибайтные блоки. А в случае работы с большими файлами можно выставить размер блоков побольше.

Но мало хранить сам файл, нам ведь нужно еще где-то хранить информацию о файле – иноду. И инода на ext4 весит 256 байт и больше. При этом, на разных типах файловых систем иноды создаются по разному – где-то они создаются динамически, когда это необходимо – так сделано в xfs, а где-то создаются сразу при создании файловой системы, как это сделано в ext4. Причём создаются они на каждые сколько-то байт, по умолчанию 16КиБ. Из этого можно извлечь пару фактов. Количество инод на ext4 – ограничено. Если у вас куча файлов, размером меньше 16 КиБ, то у вас может закончится количество инод. И тогда, хотя и будет место на диске, использовать его вы не сможете – без свободных инод файл не создать. Но, во первых, по иноде на 16КиБ получается 64 иноды на один мебибайт места, т.е. на реальных дисках вы сможете создать миллионы файлов. Во вторых, вы это значение можете изменить, сделать количество байт на инод больше или меньше. С одной стороны, уменьшив количество байт на иноду, вы сможете создавать больше файлов. С другой – посчитайте, на каждый мебибайт места вы тратите 16 КиБ на иноды, так как каждая инода весит 256 байт, а их 64. Т.е. на каждый гигабайт – 16 мегабайт чисто на иноды. На один терабайт – 16 Гигабайт. Ощутимо, правда? И это еще при стандартном раскладе. Но если у вас файлы большие, то можно и увеличить количество байт на иноду, но всё это делается при создании файловой системы. Поэтому такие вещи надо продумывать заранее – допустим, если у вас почтовый сервер, где будут миллионы писем – рассчитайте заранее, хватит ли вам инод? Ну или используйте xfs, тогда количество инод вас не будет беспокоить, так как там иноды выделяются динамически.

Для уровня «на пальцах» норм.

Для лучшего понимания рекомендую официальную документацию по дисковой структуре XFS: design/XFS_Filesystem_Structure. Оно же в виде pdf здесь.

Чтобы не только читать теорию, но и потрогать руками, рекомендую утилиту xfs_db из пакета xfsprogs. Для ext* есть утилита debugfs из e2fsprogs.

Большое спасибо