LINUX.ORG.RU

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

 , ,


4

4

Собственно, накатил Линукс на SSD, выбрал в качастве ФС F2FS и почему-то не смог найти список опций для этой ФС.

Как включить сжатие в этой ФС?

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

Нужно ли включать discard (слыхал что у F2FS какой-то свой алгоритм дискарда, но включен ли он по умолчанию, Х/З)?

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

defaults 0 0

anonymous
()

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

anonymous
()

Для начала

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

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

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

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

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от greenman

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

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

Vochatrak-az-ezm ★★
() автор топика
Ответ на: комментарий от Harliff

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

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

qtm ★★★
()
Ответ на: комментарий от qtm

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

sudopacman ★★★★★
()
Последнее исправление: sudopacman (всего исправлений: 1)
Ответ на: комментарий от sudopacman

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

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

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

qtm ★★★
()
Ответ на: комментарий от anonymous

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

qtm ★★★
()
Ответ на: комментарий от qtm

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

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

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

sudopacman ★★★★★
()
Ответ на: комментарий от qtm

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

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.

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

Vochatrak-az-ezm ★★
() автор топика
Ответ на: комментарий от sudopacman

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

qtm ★★★
()
Ответ на: комментарий от Vochatrak-az-ezm

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

qtm ★★★
()
Ответ на: комментарий от qtm

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

sudopacman ★★★★★
()
Последнее исправление: sudopacman (всего исправлений: 1)
Ответ на: комментарий от nanosecond

¯\_(ツ)_/¯

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

sudopacman ★★★★★
()
Ответ на: комментарий от sudopacman

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

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

Vochatrak-az-ezm ★★
() автор топика
Ответ на: комментарий от Vochatrak-az-ezm

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

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

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

sudopacman ★★★★★
()
Ответ на: комментарий от Vochatrak-az-ezm

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

Для 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
QsUPt7S ★★
()
Ответ на: комментарий от QsUPt7S

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

zemidius
()
Ответ на: комментарий от zemidius

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

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

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

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

zemidius
()
Ответ на: комментарий от Jameson

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

zemidius
()
Последнее исправление: zemidius (всего исправлений: 1)
Ответ на: комментарий от zemidius

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.

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

Jameson ★★★★★
()
Ответ на: комментарий от zemidius

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

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

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

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

zemidius
()
Ответ на: комментарий от zemidius

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

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

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

zemidius
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.