Ext4 дороже, чем NTFS?


11

Я только что преобразовал раздел NTFS в ext4, однако общее пространство кажется уменьшенным с 421G до 415G. Куда делись 6G? И зарезервированное пространство увеличено до 199M в ext4, намного больше, чем 78M в NTFS, почему?

Этот раздел в основном используется для фильмов / музыки, поэтому большинство файлов очень большие (> 10M каждый). Я хочу использовать файловую систему ext4, есть предложения?

mkfs.ntfs:
    /dev/sdb4             421G   78M  421G   1% /mnt/mmedia

mkfs.ext4:
    /dev/sdb4             415G  199M  393G   1% /mnt/mmedia
                       (415G - 199M == 393G ?)

Также странно, что оставшийся размер ext4 равен 393G, не должен ли он быть 415G или 414G? Что случилось с пропавшим 22G? По сравнению с NTFS ext4 потребляла 6,6% общего пространства, это действительно большая проблема.

Вопрос в том:

  1. Для чего в основном используется 6G, для журнала, для резервирования или для индексации?
  2. Почему оставшееся пространство 393G не 415G? Есть отверстие 22G, которое довольно большое.
  3. Какие параметры вы бы посоветовали, если этот раздел ext4 используется для хранения фильмов / музыкальных файлов? Говорят, что ext4 работает лучше, чем ext3 для больших разделов, правда? Я не вернусь к ext2, который не является журналом.

Ответы:


8

Для чего в основном используется 6G, для журнала, для резервирования или для индексации?

(Пока неизвестно.)

Почему оставшееся пространство 393G не 415G? Есть отверстие 22G, которое довольно большое.

Это 5% зарезервированных блоков для суперпользователя, который используется, чтобы избежать фрагментации. Вы можете настроить его на 1% mkfs.ext4 -m 1.

Какие параметры вы бы посоветовали, если этот раздел ext4 используется для хранения фильмов / музыкальных файлов?

Вы можете указать параметр использования для mkfs.ext4, например, mkfs.ext4 -T large_fileэто позволит mkfs.ext4 определять параметры для разделов, содержащих большие файлы.


1
6G будет для списков инодов.
Sirex

1
Зарезервированные блоки также ограничивают воздействие атаки типа «отказ в обслуживании», когда обычные пользователи заполняют диск до такой степени, что файлы журнала больше не могут быть записаны. Зарезервированное пространство по крайней мере даст корневым журналам достаточно журналов, чтобы поймать обидчика.
MSalters

Мой /etc/mke2fs.conf говорит о параметрах «largefile» и «largefile4» для -T, а не «large_file».
user1338062

4
  1. 6ГБ это inode. ext4 по умолчанию 1/64 (1,56%) для inode, каждый 256B; так можно заполнить 16 КБ файлами
  2. Доступное пространство df исключает пространство, зарезервированное для root, по умолчанию 5%, используйте tune2fs -m
  3. mkfs.ext4 -m 0 -N 4000000 / dev / что угодно # переформатов, 0 зарезервировано, 4 миллиона инодов используют 1 ГБ
  4. ext4 fsck намного быстрее, чем ext3; кроме этого вы не заметите никакой разницы

Каждый файл / каталог нуждается в 1 иноде. Вы не можете изменить количество inode после создания файловой системы ext. Даже 1000000 инодов будет достаточно для этого раздела, если вы будете использовать его только для фильмов и музыки.

Таблица основных файлов NTFS (MFT) немного более гибкая, поэтому NTFS может вместить больше данных по умолчанию.

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


Each inode 256B, so can fill with 16KB filesВы имеете в виду, что в каждом иноде 16K-256 = 16128 свободных байтов?
Xiè Jìléi

1
Я имею в виду, что если вы используете 1/64 устройства для таблиц инодов, а каждый инод равен 256B, то вы получаете один инод на 16 КБ устройства ... на самом деле это 1 инод на 15,75 КБ оставшегося устройства, но достаточно близко. Таким образом, у вас достаточно инодов, чтобы заполнить весь диск 16-килобайтными файлами. Если вы ожидаете иметь гораздо большие файлы, например видео, вы можете обойтись меньшим количеством inode и сэкономить, возможно, несколько ГБ на устройстве.
Сэм Уоткинс

3

Да, это аккуратная маленькая тема. Каждая файловая система реализует свои структуры данных по-своему. Вы можете попробовать отформатировать раздел с различными файловыми системами и сравнить его. «Свободное» пространство будет отличаться. Кроме того, по мере их заполнения будет происходить различие в накладных расходах хранилища, и поэтому в некотором смысле объем памяти, необходимый для хранения одного и того же файла, может отличаться в зависимости от файловой системы. Обычно, когда вы форматируете файловую систему, вы также можете выбрать некоторые параметры для ее организации - это тоже оказывает влияние.

Ответ на ваш вопрос - один из тех, что «зависит» . Я думаю, что в целом 6/400 ГБ - не страшная разница, но, действительно, это заметно. Тем не менее, место для хранения становится все дешевле и дешевле. Но я думаю, что файловые системы, вероятно, становятся все тяжелее, поскольку нам нужны более интересные функции. Я подозреваю, что ext2 чуть-чуть худее, чем ext4. Мне было бы интересно увидеть некоторые реальные цифры по этому вопросу. Конечно, эта «эффективность» имеет свою цену (самая большая из них заключается в том, что она не заносится в журнал и, следовательно, быстрее и легче повреждается).

Что касается того, почему ext4 занимает больше места в этом случае, я предполагаю, что ваши кластеры хранения в NTFS были настроены так, чтобы адрес вашего пространства хранения был гораздо большими блоками, чем требовали ваши параметры ext4. Если это так, то вы должны более эффективно использовать хранилище, если у вас много относительно небольших файлов.

Достаточно сказать, что весь предмет продолжается и продолжается. Если вам нужна дополнительная информация, я бы посоветовал взглянуть на различные страницы Википедии, сравнивая там файловые системы. А также посмотреть справочные страницы для каждой интересующей вас FS.

Надеюсь, вы найдете это полезным.


1

Зарезервированные суперблоки - это одно, но не та сумма, на которую вы ссылаетесь. Изменение зарезервированных суперблоков не отображается в «общем доступном пространстве» ... это не изменяется. Это число инодов x их размер. По умолчанию в ext4 ожидается что-то вроде 256 байтов на инод и для 400 ГБ Я предполагаю, что mkfs.ext4 будет делать ~ 25-30 млн. Используйте dumpe2fs -h, чтобы увидеть фактическое число. Это составляет 6 ГБ, которые вы пропустили, а не зарезервированные блоки, о которых кто-то говорит (например, подсчитать x размер inode b / 1024 ^ 3) ГБ.

Я подозреваю, что вывод df -h может быть связан с некоторой хромотой; p Попробуйте сделать это снова и укажите половину ваших i-узлов (вы можете сделать это безопасно, и даже больше, если вы смелы), но помните, что множество каталогов может заставить вас исчерпать иноды перед пробелом.

Например. ext4 резервирует несколько 93-4?) inode для каждого каталога, предполагая, что вы намереваетесь хранить более одного или двух файлов, и, таким образом, повышаете его эффективность. Тем не менее, если у вас есть 1 миллион папок с 1 миллионом файлов, у вас не хватит inode на этом макете, прежде чем вы фактически исчерпаете пространство. Обычно иноды используются только в пределах нескольких процентов пространства, но могут достигать 35%, поэтому деление на два довольно безопасно для пользователей настольных компьютеров, но не нужно делать больше для безопасности.

Вот пример:

RAW 415 ГБ (скажем, dev / sdb1) mkfs.ext4 -m0 -Ndefault # / 2 -Lext4-1 -O экстент, dir_index, большой_файл, sparse_super, uninit_bg / dev / sdb1

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

Малина салина


0

У меня была (полная) файловая система ntfs, содержащая около 1000 ГБ данных, и всего несколько сотен мегабайт. Даже если отформатированная емкость ext4 была намного меньше, чем у ntfs, я помню, что когда я все копировал, у меня все еще оставалось около 70 ГБ свободного места на ext4, даже если отформатированная емкость была меньше. (Помните, что NTFS был полон). Я не могу обещать, что это произойдет с вами, но, по крайней мере, для файлов, которые у меня были ext4, было очень сложно! :)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.