ФС для SSD с минимумом потраченного места

которая не жрет гигабайты под служебные структуры и прочую хрень

Такой не существует.

Надо, чтобы жрала мегабайты

xfs и не упарывайся всякой наркоманией.

FAT? Довольно компактная ФС.

Под корень как-то не)

Так ssd аппаратно на порядок больше жрет ресурса, чем любая ФС. Если забъешь ssd по завязку — будет тормоз на уровне железа. Так что не страдай фигней.

Такой не существует. Почитайте о том, как устроены ФС.

У XFS минимальные дефолтные накладные расходы:

На вновь созданной файловой системе XFS на служебные нужды тратится порядка 0,54 %.

BTRFS

squashfs

UFS2+SU без J.

Советую использовать Ext4.

Спуфи? Даже дешевого 120гб сосунга хватит за глаза, без всяких микрооптимизаций.

btrfs с включенным сжатием порвет всех в этом случае

squashfs [2]

Как сжатие избавит от метаданных? У меня при 43 Гб данных - 1 Гб метаданных.

Если чел задумался о миминизации потерь места и смотрит с интересом в сторону размера метаданных, то может челу лучше посмотреть с интересом в сторону сжатия?

1 Гб метаданных на меньше чем 50 Гб данных это трудно назвать эффективным расходованием места. Btrfs не для экономии места на накопителе.

Профит от сжатия данных перекрывает даже сильно разжиревшие метаданные. Ну и это, ты судишь по одному маленькому SSD, а у меня и на 3 Тб вроде было 2 Гб метаданных. Если не забуду, проверю при случае.

у меня и на 3 Тб вроде было 2 Гб метаданных

Чот не верится.

Профит от сжатия данных перекрывает даже сильно разжиревшие метаданные

Ну хз, хз, тут без точных тестов не скажешь. Тем более, что у меня Btrfs монтируется с опцией max_inline=256, т.е. в дерево метаданных включаются только файлы размером 256 байт и менее, остальные выносятся и подвергаются сжатию. По дефолту в дерево включаются файлы до 4 Кб, а это делает его ещё более жирным.

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

Не поможет.

Чот не верится.

А ты проверь. Кроме того, когда ты говоришь про 1Гб, ты говоришь скорее всего про аллоцированный чанк. Сколько реально используется по выводу btrfs fi us?

По дефолту в дерево включаются файлы до 4 Кб, а это делает его ещё более жирным.

Не путай метаданные с инодами.

Пример:

pve ~ # btrfs fi us /mnt/
Overall:
    Device size:                   4.00TiB
    Device allocated:              2.02GiB
    Device unallocated:            4.00TiB
    Device missing:                  0.00B
    Used:                        512.00KiB
    Free (estimated):              4.00TiB      (min: 2.00TiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:               16.00MiB      (used: 0.00B)

Data,single: Size:8.00MiB, Used:256.00KiB
   /dev/mapper/storage-test        8.00MiB

Metadata,DUP: Size:1.00GiB, Used:112.00KiB
   /dev/mapper/storage-test        2.00GiB

System,DUP: Size:8.00MiB, Used:16.00KiB
   /dev/mapper/storage-test       16.00MiB

Unallocated:
   /dev/mapper/storage-test        4.00TiB

2 Гб выделенных

Да, и это DUP ещё.

когда ты говоришь про 1Гб, ты говоришь скорее всего про аллоцированный чанк

Нет, про занятое место.

# btrfs fi df /
Data, single: total=70.51GiB, used=46.39GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=3.01GiB, used=1.03GiB
GlobalReserve, single: total=212.89MiB, used=0.00B

Не путай метаданные с инодами

Иноды это и есть метаданные.

смутно припоминаю, что на четырёхтерабайтном диске, забитом на 3 Тб типичным домашним хламом, использование метаданных держалось в районе сотен Мб из 2 Гб выделенных

Такого быть не может.

Эээ, да, возможно, я помню плохо. Если на NAS буду делать btrfs под бэкапы, то смогу проверить.

Иноды это и есть метаданные.

Сомневаюсь. В описании формата у них INODE_ITEM вместе с EXTENT_DATA в FS_TREE, а это однозначно данные. А вот другие деревья уже должны относиться к метаданным, хотя насчёт checksum tree не уверен.

ext4 по умолчанию создает очень много inode на больших дисках, и резервирует еще место под новые inode, если в будущем будет производится ресайз ФС.

Я обычно создаю ФС для корня так:

mkfs.ext4 -m0 -O \^resize_inode -N 6M

Экономнее всех - reiser4, только для рутовой партиции не получится noatime выставить.

https://reiser4.wiki.kernel.org/images-reiser4/f/fb/Compilebench-0.6.pdf

1 Гб метаданных на меньше чем 50 Гб

$ sudo btrfs fi df /          
Data, single: total=98.00GiB, used=15.81GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=446.17MiB
GlobalReserve, single: total=50.75MiB, used=0.00B

$ sudo btrfs fi df /mnt/data
Data, RAID5: total=2.98TiB, used=2.91TiB
System, RAID1: total=32.00MiB, used=240.00KiB
Metadata, RAID1: total=5.00GiB, used=2.63GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

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

О, спасибо, теперь я не так сомневаюсь в своей памяти.

RAID5

Неужто до сих пор не рассыпалось?

Неужто до сих пор не рассыпалось?

А должно было?

Скажу больше — она уже один ребилд пережила и ряд тихих ошибок, найденных скрабом.

для рутовой партиции не получится noatime выставить

mount / -o remount,noatime не срабатывает?

Ну не знаю, 5/6 даже официально не для использования.

ряд тихих ошибок, найденных скрабом

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

У reiser4 нет ремаунта. Вот тут что-то было: https://sourceforge.net/p/reiser4/discussion/general/thread/db091215/

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

интересно как она себя будет вести по мере заполнения https://askubuntu.com/a/131551

Плюсую F2FS.