Оверхед ext3/4

Интересно, какой смысл вкладывают люди задающие такие вопросы в слово «отформатировал»? Служебная информация пишется? Пишется. Место она должна занимать? Должна. Сколько процентов от полутора терабайт занимает 26ГБ? А сколько съестся у 80ГБ в процентах? А когда на 3ТБ винт купите и служебная информация съесть 40 Гб тоже в дженерал тему будете создавать?

Неужели windows уже поддерживает ext4?

1) Резервирование можно сделать 0.01% или около того
2) количество инодов лучше убавлять с умом, если они кончатся, то новые файлы/каталоги не сможешь создать

26гб - слишком много. При миллионе inode служебная информация занимает всего 500мб.

Не нравится — пользуйтесь ZFS.

Для файловой системы в 1Гб битовая карта займет 32Кб — её можно держать в оперативной памяти и довольно быстро сканировать для поиска свободного пространства. Для файловой системы в 1Тб размер битовой карты составит уже 32 Мб — такой объём ещё можно уместить в оперативной памяти, но это уже нетривиально в смысле размера и времени сканирования. Битовая карта для файловой системы в 1Пб потребует уже 32Гб, и уже просто-напросто не поместится в оперативной памяти большинства машин. Следовательно, сканирование битовой карты в этом случае потребует её чтения с диска, который намного медленнее оперативной памяти.

Ясно, что такой способ плохо масштабируется.

Очевидным выходом является разделение битовой карты на небольшие части и хранение количества битов, установленных в каждой из них. Например, для файловой системы в 1Пб с размером блока в 4Кб, свободное пространство может быть разделено на миллион битовых карт, размер каждой из которых составит 32Кб. Сводная информация — миллион целых чисел, хранящих количество установленных битов в соответствующей битовой карте — уже поместится в оперативной памяти, поэтому можно будет достаточно легко найти битовую карту со свободным местом и просканировать её для поиска места.

Но это не избавляет нас от одной фундаментальной проблемы: битовые карты нужно обновлять не только когда выделяется новый блок, но и тогда, когда блок освобождается. Файловая система может управлять локальностью выделяемых блоков (решать, в каком месте размещать новые данные), но не имеет никакого способа влиять на положение освобождаемых блоков. Простая команда вроде 'rm -rf' может вызвать освобождение блоков, разбросанных по всему диску. Например, удаление 4Гб данных (т.е. миллиона блоков по 4Кб) из нашей файловой системы размером в 1Пб потребует, в худшем случае, чтения, изменения и повторной записи миллиона битовых карт. Это означает два миллиона дисковых операций ввода/вывода для освобождения каких-то 4Гб — что неразумно даже в худшем случае.

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

Сбалансированные деревья

<...>

карты пространства [ZFS] имеют прекрасное свойство: по мере приближения заполненности пула к 100%, карты пространств начинают буквально «испаряться», занимая всё меньше и меньше места, давая возможность максимально использовать имеющееся дисковое пространство для хранения полезной информации.

http://blogs.sun.com/bonwick/ru/category/ZFS

>карты пространств начинают буквально «испаряться», занимая всё меньше и меньше места, давая возможность максимально использовать имеющееся дисковое пространство для хранения полезной информации

о как) ntfs во все поля!

Да не то, что не нравится, просто интересно, почему при создании ФС со стандартными параметрами будет 50 миллионов инодов. Причем отжирают они 26гб.

Что лучше, кусать локти когда иноды кончатся, или потерять 0.1% места?

Да вообще-то чуть меньше 2%, а не 0.1%. У меня сейчас используется около миллиона инодов, причем у меня куча ненужных файлов. Хочу ставить линукс на ноутбук, там больше 2 миллионов инодов использоваться точно не будет.

> Что лучше, кусать локти когда иноды кончатся, или потерять 0.1% места?

Лучше иметь динамические метаданные, тогда в каждый момент времени они будут занимать ровно столько места, сколько нужно в этот момент времени.

> 26гб - слишком много.
Это нормально

При миллионе inode служебная информация занимает всего 500мб.

И что?

Да не то, что не нравится, просто интересно, почему при создании ФС со стандартными параметрами будет 50 миллионов инодов.

echo 1500*1024*1024/4/50000000 | bc
7.86432000000000000000
Один инод на 8 четырёхкилобайтных блоков. В чём криминал?
А сколько должно быть?

Причем отжирают они 26гб.

Сколько должны, столько и отъели.

> Лучше иметь динамические метаданные, тогда в каждый момент времени они будут занимать ровно столько места, сколько нужно в этот момент времени.

И что это даст? Когда на диск мало написано, то какая разница, сколько занято метаданными? Когда диск под завязку, то размер метаданных будет тем же самым. Какая разница?

Use XFS, Luke.

> И что это даст? Когда на диск мало написано, то какая разница, сколько занято метаданными? Когда диск под завязку, то размер метаданных будет тем же самым. Какая разница?

А ты подумай. Подсказываю - дело не только в размере.

Какие тут все загадочные, это что-то.

Если тебя так заботит этот момент, используй XFS.

> Какие тут все загадочные, это что-то.

Не надумал? Ну ладно. Ответ, лежащий на поверхности - не надо задумываться в момент создания системы, о том, сколько и каких в ней будет файлов. 26 гигов пространства - это все-таки ощутимый объем, и представь - тебе понадобилось ну вот еще 10 гигов места, а нету.. Файлов мало, они большие, метаданных столько не нужно, место, занимаемое метаданными, пустует. Вот бы его использовать - а нет, нельзя. Покупай еще один диск. А под него надо место. А если места под еще один диск нет? Новый сторадж. А под него тоже надо место.. Ну так и до нового датацентра дойти можно. Утрирую конечно :-)

Ну или наоборот - создал вот товарищ ФС с параметрами по умолчанию, увидел что 26 гиг ушло под хз что. А тут зеленое земноводное ему и говорит: «куда тебе столько 100500 файлов, всем должно хватать 25125». Ну он хрясь - и переделывает все, и обрадованный забывает.. А через некоторое время начинает удивляться, почему это ошибки лезут? Места вроде много. А вот поди ж ты, не надо было жабу слушать.

Далеко не всегда ведь можно знать заранее, сколько и чего понадобится через месяц, три, полгода, год..

Ну и потом, фиксированные метаданные - это хотспоты на диске... Что может быть не очень хорошо.

Как-то хотел домашний раздел перевести с reiserfs3 на ext4, создал в lvm пустой том такого же размера, стал копировать файлы. И блин, на разделе с reiserfs3 было полгига места, а для ext4 места не хватило. А ну его в дупу, что ли, этот ext4.

> Не надумал?
И не собирался

Литературные изыски комментировать не хочется. 26 гиг большим кажется только на первый взгляд. Динамические метаданные это хорошо только с одной стороны. С точки зрения сложности FS и оверхеда на выделение/убирание динамических служебных данных вопрос этот не настолько однозначный.

>количество инодов лучше убавлять с умом, если они кончатся, то новые файлы/каталоги не сможешь создать

А разве ext4 всё ещё не умеет динамически иноды аллоцировать?

Во жмотовилы пошли, жалко под служебную информацию с 1.5 Тб всего 26 гигов.

Совковый синдром, никак иначе. Странно что не жалуется на что на винте 1500000000000 байт вместо 1649267441664

>А разве ext4 всё ещё не умеет динамически иноды аллоцировать?
Вроде как только при увеличении раздела, хотя не уверен

миллион имхо мало очень.

> 26 гиг большим кажется только на первый взгляд.

Конечно, щас же винты уже вон по три тера пошли, что такое 26 гиг? сущая ерунда.

Динамические метаданные это хорошо только с одной стороны.

Ну дык пока еще медалей с одной стороной не придумали.

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

Боюсь, ты недооцениваешь оверхед, связанный с обработкой статических метаданных.

Ровные поцаны форматируют так:

mkfs.ext4 -O ^filetype,^resize_inode,^ext_attr -m 0 -I 128 ...

Почему по умолчанию такой большой оверхед?

man resize inode

>всего 26 гигов.

Е***ь, у меня во втором компе 80G весь hdd.

Какие иноды на _пустом_ разделе?

# mkfs.ext4 111; mount 111 /media/ -t ext4

# df -h |grep media
/dev/loop0 415M 11M 384M 3% /media

# mkfs.ext4 -O ^resize_inode -m 0 -I 128 111; mount 111 /media/ -t ext4

# df -h |grep media
/dev/loop0 415M 8,1M 407M 2% /media

Вот эти 8,1M - это журнал. Если его отключить, занято 20 килобайт.

>Служебная информация ... Место она должна занимать?

На пустом разделе _не должна_.

>у меня во втором компе 80G весь hdd.

А у меня есть диск с 20 гигами, был вернее...

У меня wd caviar на 200M(мегабайт) есть, но это не говорит о том, что нужно впустую тратить дисковое пространство.

Какая тебе разница, сколько занята на пустом разделе, если на полном она большей частью понадобится? Считай, что место _зарезервировано_, т.е. свободно, но недоступно. NTFS тоже 12% места резервирует — и ничего, никто не расстраивается

>У меня wd caviar на 200M(мегабайт) есть, но это не говорит о том, что нужно впустую тратить дисковое пространство.

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

И вам читать в гугле на предмет resize inode. Мне оно не нужно.

>Быстродействие, надежность и простота

Mr. Джопс, вы?

В венде теперь есть поддержка ZFS?

>Mr. Джопс, вы?

А что вам не нравится в сказанном?

То, что это высер. Я настрою так, как мне на самом деле удобнее/эффективнее. Всё перечисленное перпендикулярно друг другу, и в пределах некоторой одной фс не реализовано.

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

Дык отключил ;)

>Я настрою так, как мне на самом деле удобнее/эффективнее.

Я говорил про настройки по умолчанию.

Всё перечисленное перпендикулярно друг другу,

Таблица inode - простой, надежный и быстрый способ. Что вам не нравится?

>Я говорил про настройки по умолчанию.
Не всех устраивают, этот тред в подтверждение.

Таблица inode ... Что вам не нравится?

Ещё раз, внимательно, вдумчиво перечитывать мои предыдущие посты.

Кури mke2fs на предмет опции -T. В редхетовых дистрах определены следующие типы: news, lagrefile, largefile4 (и еще некоторые, см. /etc/mke2fs.conf) — можно выбрать по вкусу. Но только не плачь потом, что inode кончились.

>Ещё раз, внимательно, вдумчиво перечитывать мои предыдущие посты.

Вы про resize_inode? Оно что, отменяет все достоинства статически зарезервированной таблицы?

Совсем упоротый?

У себя хомяк отформатировал так:
mkfs.ext4 -O ^filetype,^resize_inode,^ext_attr,^huge_file,^extra_isize,^dir_nlink -m 0 -I 128 ...

Пояснения относительно отключаемых опций здесь.

Теперь главный вопрос: а зачем? Затормозить, слишком быстро работает?

Наоборот. Я предполагал, что более маленький инод и отключение некоторых фич ускорит работу. Впрочем, на быстродействие это не повлияло. На чтении мелких файлов ext2 сильно быстрее.

не вижу O^has_journal :))

я бы больше грешил на барьеры: пробуем опции монтирование barrier=0 (или nobarrier), data=writeback