выбор фс для ssd

btrfs - идеальна для SSD

ну вот тоже склоняюсь к тёмной стороне. Возможно даже табличку накалякаю.

f2fs

читаю ман MKFS.BTRFS
вот хоть убей, не могу найти размер блока.
-n|--nodesize <size>

+ -l|--leafsize <size>:: Specify the nodesize, the tree block size in which btrfs stores data. The default value is
16KB (16384) or the page size, whichever is bigger. Must be a multiple of the sectorsize, but not larger than 65536.
Leafsize always equals nodesize and the options are aliases.

ноудсайз это в бтрфс вместо размера блока? т.е. нода=блок?

Собственно, ext4 не умеет большие блоки

В чем преимущество использования больших блоков?

+42 к скорости

ну хотя бы спросил)
смотри таблицу, ниже слов
The output of the script is a list of the tested block sizes and their respective transfer rates like so:

http://blog.tdg5.com/tuning-dd-block-size/

если быть точнее, то +3 гб/с

Linus Torvalds has a classic rant on the subject at realworldtech.com (the rant starts a page into his post):

I've actually done the math. Even 64kB pages is totally useless for a lot of file system access stuff: you need to do memory management granularity on a smaller basic size, because otherwise you just waste all your memory on unused left-over-space.

and

So reasonable page sizes range from 4kB to 16kB (and quite frankly, 16kB is pushing it - exactly because it has fragmentation issues that blow up memory usage by a huge amount on some loads). Anything bigger than that is no longer useful for general-purpose file access through mmap, for example.

and

For a particular project I care about, if I were to use a cache granularity of 4kB, I get about 20% lossage due to memory fragmentation as compared to using a 1kB allocation size, but hey, that's still ok. For 8kB blocks, it's another 21% memory fragmentation cost on top of the 4kB case. For 16kB, about half the memory is wasted on fragmentation. For 64kB block sizes, the project that takes 280MB to cache in 4kB blocks, now takes 1.4GB!

сферический тест в вакууме.

Я в дисковой подсистеме зеленый, но чем грозит

ext4 не умеет большие блоки

P.S. использую ext4 на SSD и не испытываю никаикх проблем.

ну мне и нужно 16к)

dd уже не рулит, дааа?

выше бенч же

мерит скорость dd, все равно, что мерить скорость человека, когда он падает с небоскрёба, ведь вывод, что человек по вертикали двигается быстрее, чем по горизонтали, а ещё вывод можно сделать такой, что человек может перемещаться со скорость 180 км/ч.

да ладно, есть даже специальная олимпиада по перемещению человека по вертикале: http://www.speed-skydiving.com/index.php/rankings

557,57 kmph

я про свободное падение

ssd
большие блоки

не нужно

тесты сестра, тесты!

Ага, с большим блоком /dev/zero в /dev/null быстрее перегоняется, на 3гб/с быстрее. Очень надёжный и показательный тест. Ты на своём-то SSD этот тест пробовал гонять?

NTFS

каникулы чтоле?

Собственно, ext4 не умеет большие блоки

Умеет.

mke2fs -C 64k -O bigalloc -t ext4 -v /dev/sdX

Но это всё зря, тк большой блок хорош для больших файлов, а для мелких посадит производительность.

ах да, для ъ: mkfs.ext4 /dev/sde -b 16k ; mount /dev/sde /media/1 -o discard

впрочем уже поздно, форматнул в f2fs)
а примнтировать с твоими параметрами на х86 смогёт?

То, что ты предлагаешь не смонтируется,

EXT4-fs (loop0): bad block size 16384

А то, что предложил я — работает.

спасибо, может позже и проверю.

А кто умеет в большие блоки и на кой хер оно тебе сдалось? ЕМНИП, везде или почти везде blocksize == pagesize (== 4K на x86).

https://lwn.net/Articles/469821/

и на кой хер

ssd выбор размера блока

Верните старого даркшвейна, он был лучше.

Так это не блоки (единицы логического ввода-вывода), а единицы аллокации.

Чё-т какой-то идиотизм. Если ты из файла читаешь большими кусками, то и с малым блоксайзом ты будешь читать ими же: block layer наверняка не настолько тупой, чтобы не объединять запросы. А если ты из файла читаешь вразнобой, то никто тебе не поможет, т. к. с большим блоксайзом блоков в секунду будет читаться столько же или меньше, просто 90% блока будет отбрасываться нахрен.

NTFS

Ещё один путает блоки с кластерами.

смогёт
ё
darkenshvein

ану акк быстро вернул! бедная даркшвайня уже яйца себе наверно оторвала!

block layer наверняка не настолько тупой

ну так посмотри в код, али виндовс ядро? :)

а ты кто ваще?

ну вот тоже склоняюсь к тёмной стороне.

Сравнение в использовании btrfs и ext4 для /var/lib/collectd (кучка rrd) не показало преимущества btrfs. И да, на ssd.

форматнул в f2fs

О, а вот F2FS я не проверял на счёт производительности на SSD. Надо поставить напоминалку...

в принципе нормально, на одном уровне с экст4.

проверял на bonnie
,relatime,background_gc=on,nouser_xattr,noacl,inline_data,extent_cache,active_logs=6)

Мне влом, я не собираюсь тебе ничего доказывать. Сам посмотри, если интересно.

Большие блоки умеет zfs, up to 1mb

я тень твоя, сдрысьни под шконку!

согласно Форониксу, f2fs - практически лидер

А ты уверен, что пытающиеся увеличить на самом деле хотят сделать это с block а не allocation unit?

Вон там вверху писали про скорость и приводили ссылку на старый тред ТСа, где он говорил про большие i/o unit. Логично, что сейчас он хочет воплотить это в жизнь. Увеличивать allocation unit может иметь смысл разве что для того, чтобы ограничить снизу размер фрагмента (при фрагментации файлов)...