Посоветуйте настройки fstab для F2FS

Какие параметры посоветуете прописать в fstab?

defaults 0 0

Посоветуйте настройки fstab для F2FS

Дефолт.

не смог найти список опций для этой ФС

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/filesystems/f2fs.rst

Спасибо.

Если у вас китайский SSD, изготовленный из компонентов SD памяти, то ничего менять не нужно - эта система как раз для такой памяти создавалась.

Отпишитесь потом, как она в сравнении с ext4, пожалуйста.

По ощущениям пошустрее чем ext4.

Для начала

https://wiki.archlinux.org/title/F2FS

По поводу сжатия — учти, что

Сжатие в f2fs не освобождает свободное место. На флеш меньше данных пишется, но для пользователя никакой разницы не будет видно.

Ну и попытайся разобраться с написанным в этом комментарии

Ну и попытайся разобраться с написанным в этом комментарии Ясно, спасибо.

Сжатие в f2fs не освобождает свободное место. Я в курсе.

В Арче по дефолту прописывается вот такая простыня. Я туда даже не заглядываю. Как говорится, работает - не трогай.

LABEL=ROOT / f2fs rw,relatime,lazytime,background_gc=on,discard,no_heap,inline_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=posix 0 0

В fstab прописывается или ты это в выхлопе mount увидел?

discard

Вот поэтому надо бы читать, что там вообще генерируется.

В fstab через genfstab.

А в чем проблема?

https://wiki.archlinux.org/title/Solid_state_drive#TRIM

И? Проблема в чем?

Чукча не читатель? Опция discard не должна быть включена. Вместо неё настоятельно рекомендуют использовать fstrim.timer (и тем более не использовать и то, и другое одновременно).

Там не говорится «не должна», там говорится что линукс-сообщество обычно предпочитает делать периодический трим и все. Если бы была «не должна», ее бы давно отрубили по дефолту где только можно.

Просто когда-то 300 лет тому назад с дискардом были проблемы, вот во имя штабильности и стали юзать фстрим.

У меня проблем нет. Диску 2 года, f2fs на нем стоит все эти 2 года, discard, соответственно 2 года включен. 10000 часов наработки, смарт показывает, что диск жив и неплохо жив.

У меня проблем нет

https://upload.wikimedia.org/wikipedia/commons/thumb/b/b2/Survivorship-bias.svg/800px-Survivorship-bias.svg.png

Вот когда смарт покажет нечто подобное, тогда я и подумаю где нужно усиливать броню.

Не, ну ты явно читать не умеешь.

Если бы была «не должна», ее бы давно отрубили по дефолту где только можно.

Ubuntu enables periodic TRIM by default [7], Debian does not recommend using continuous TRIM and Red Hat recommends using periodic TRIM over using continuous TRIM if feasible

Fedora

Странно что дискард:

By default, F2FS is mounted using a hybrid TRIM mode which behaves as continuous TRIM. This implementation creates asynchronous discard threads to alleviate long discarding latency among RW IOs. It keeps candidates in memory, and the thread issues them in idle time [7]. As a result of this, users wanting periodic TRIM will need to implicitly set the nodiscard mount option in /etc/fstab or pass it to mount if mounting manually.

И по моему сборщик мусора тоже должен быть включен по умолчанию…

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

Ну не знаю почему так. Главное, что УМВР :-)

Причём тут, что нравится, а что не нравится? Я тебе привёл непосредственные пруфы, что её «отрубили по дефолту где только можно». Ты мне лучше найди, где советуют / используют по умолчанию discard вместо fstrim.timer.

у меня завершался с ошибкой fstrim.timer если не указан discard как тебе такое)

Ты настройки LUKS/LVM с опциями монтирования случаем не путаешь? 

нет

Человеки, а как собственно проверить - работает ли трим, или нет?

¯\_(ツ)_/¯

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

systemctl status fstrim

Эта хрень покажет работает ли юнит, а мне надо узнать работает ли трим в принципе.

Есть возможность посмотреть как фрагментацию, мол столько-то ячеек жаждет трим.

Так если trim работает, что в выхлопе будет что-то типа

fstrim: /: <...> GiB (<...> bytes) trimmed on /dev/<...>

Можно ещё руками fstrim вызвать.

lsblk --diskard

Есть возможность посмотреть как фрагментацию, мол столько-то ячеек жаждет трим.

Для f2fs, кучу статистики по конкретному разделу можно посмотреть в /sys/fs/f2fs/.

$ls -w 80 /sys/fs/f2fs/sda1
atgc_age_threshold       feature_list           max_small_discards
atgc_age_weight          features               max_victim_search
atgc_candidate_count     free_segments          migration_granularity
atgc_candidate_ratio     gc_background_calls    min_fsync_blocks
avg_vblocks              gc_foreground_calls    min_hot_blocks
batched_trim_sections    gc_idle                min_ipu_util
ckpt_thread_ioprio       gc_idle_interval       min_seq_blocks
compr_new_inode          gc_max_sleep_time      min_ssr_sections
compr_saved_block        gc_min_sleep_time      mounted_time_sec
compr_written_block      gc_no_gc_sleep_time    moved_blocks_background
cp_background_calls      gc_pin_file_thresh     moved_blocks_foreground
cp_foreground_calls      gc_reclaimed_segments  node_io_flag
cp_interval              gc_segment_mode        ovp_segments
current_reserved_blocks  gc_urgent              ram_thresh
data_io_flag             gc_urgent_sleep_time   ra_nid_pages
dir_level                idle_interval          readdir_ra
dirty_nats_ratio         iostat_enable          reclaim_segments
dirty_segments           iostat_period_ms       reserved_blocks
discard_granularity      ipu_policy             seq_file_ra_mul
discard_idle_interval    lifetime_write_kbytes  stat
encoding                 main_blkaddr           umount_discard_timeout
extension_list           max_io_bytes           unusable

Спасибо.

Это из-за кривых ssd сделали.

На нормальных ssd (коих большинство) спокойно включается discard и забот нет

Это из-за кривых ssd сделали.

Жаль что на упаковке ssd не сообщается заранее, нормальный он, или кривой… :(

Ну так голова человеку дана не только, чтобы туда есть ))

Это ещё и для тех у кого SATA3.0 сделали. Там discard передаётся как высокоприоритетная операция и постоянно ломает очередь команд. Из за чего снижается производительность и контроллер SSD в целом начинает работать неэффективно. Так что разумнее давать discard сразу на все свободные блоки пачкой раз в сутки например, чем ломать диску очередь при каждой операции удаления, если discard используется как опция монтирования. В sata3.1 это исправлено. В NVMe всё изначально в порядке.

Там discard передаётся как высокоприоритетная операция и постоянно ломает очередь команд. Из за чего снижается производительность и контроллер SSD в целом начинает работать неэффективно

Можно плз пруф?

https://en.wikipedia.org/wiki/Serial_ATA#SATA_revision_3.1

Queued TRIM Command, improves solid-state drive performance.

Я trim discardом назвал, как в fstab, но суть одна.

Нет, про Queued Trim в SATA3.1 я знаю. Я спрашивал пруф на «постоянно ломает очередь команд. Из за чего снижается производительность и контроллер SSD в целом начинает работать неэффективно».

https://en.wikipedia.org/wiki/Trim_(computing)#Disadvantages

The original version of the TRIM command has been defined as a non-queued command by the T13 subcommittee, and consequently can incur massive execution penalty if used carelessly, e.g., if sent after each filesystem delete command. The non-queued nature of the command requires the driver to first wait for all outstanding commands to be finished, issue the TRIM command, then resume normal commands. TRIM can take a lot of time to complete, depending on the firmware in the SSD, and may even trigger a garbage collection cycle. This penalty can be minimized in solutions that periodically do a batched TRIM, rather than trimming upon every file deletion, by scheduling such batch jobs for times when system utilization is minimal. This TRIM disadvantage has been overcome in Serial ATA revision 3.1 with the introduction of the Queued TRIM Command.

Ссылки на первоисточники найдёшь в статье.

Ну там же не зря пометили это как «citation needed», это просто написанные кем-то слова в википедии без пруфа.

Да мне как то всё равно веришь ты википедии или нет. Компьютер твой, поступай с ним как хочешь.

Понятно. Пруфа нет, а жаль.

Я не понимаю пруф чего тебе нужен? Есть описание как работал трим в стандарте 3.0, есть понимание того что это было неэффективно, есть описание изменения поведения в стандарте 3.1 по причине понимания.

Я не понимаю пруф чего тебе нужен?

Ну очевидно же вроде. «can incur massive execution penalty» - вот этого. Сколько раз/процентов хотя бы. Я не наблюдал нигде.

Ну а чего ты до меня додолбался то? У подкомитета Т13 спрашивай, на каких основаниях они принимали решение вначале и почему потом решили изменить поведение в следующей версии стандарта. Я вот тоже живого суслика никогда не видел, но знаю что они есть.

Да блин, без претензий я, не видно что ли? )) Я просто хочу нормальные пруфы, вдруг кто видел (я - искал и не нашёл).