pingtoo wrote:towel1,
May I suggest if you could listing each option you choose with reason in your own words. This way it could reach wider audiences not just only those familiar to F2FS. As I am don't use F2FS but very much want to move to for some of my devices. I know some of the standard options like 'rw', 'noatime' but none of those specific to F2FS.
I guess it will be easier for those experts that understand why you choose these options could make better comments.
yeah I wrote the OP in a hurry to put it out
I don't have a deep rationale for choosing F2FS, and I chose those mount options like I was adding spices to a recipe, looking at the F2FS mount options and adding whatever looked yummy/spicy.
I feel like F2FS needs more documentation. I feel like that besides that link from OP, you gotta read commit messages, mailing list, and reverse engineer its source code to enhance understanding, which is very cumbersome tiresome.
Gentoo's wiki is
too much succinct, it doesn't mention flags required to mkfs.f2fs or mount:
https://wiki.gentoo.org/wiki/F2FS
but Arch's wiki has additional more mature advice:
https://wiki.archlinux.org/title/F2FS
from Arch's wiki, it states to format a partition, among three options,
specifically with:
Code: Select all
# mkfs.f2fs -l mylabel -O extra_attr,inode_checksum,sb_checksum,compression /dev/sdxY
additionally, when creating the partition, I added lost_found to the -O option list. man page for mkfs.f2fs mentions casefolding a few times, I have no idea what it means, and I didn't overthink about it, dunno what are their implications.
and
recommended mount options:
Code: Select all
# mount -o compress_algorithm=zstd:6,compress_chksum,atgc,gc_merge,lazytime /dev/sdxY /mnt/mountpoint
so on top of those recommended options explained in wiki.
zstd is kinda slow with high compression gains. but I fear that too much compression, would throw away the benefits of fast SSD, because CPU would be bottleneck compressing and decompressing. I dunno how to measure that. I feel like compression only matters when SSDs are used for cold storage, or to maximize its lifespan. for daily usage, kinda sus?
you see. lz4 is a very fast algorithm with slim compression gains. I chose the lowest compression level for lz4. my idea was the following: do compress a little, if you can save one or two blocks from being written, fine, otherwise, fine. decompression is enormously fast, minimal overhead (but again, I dunno how to measure)
I also added fsync_mode=strict. look at this (emphasis mine):
Control the policy of fsync. Currently supports “posix”, “strict”, and “nobarrier”. In “posix” mode, which is default, fsync will follow POSIX semantics and does a light operation to improve the filesystem performance. In “strict” mode, fsync will be heavy and behaves in line with xfs, ext4 and btrfs, where xfstest generic/342 will pass, but the performance will regress. “nobarrier” is based on “posix”, but doesn’t issue flush command for non-atomic files likewise “nobarrier” mount option.
I didn't verify this claim, but makes you think. F2FS is widely criticized for being unreliable. so I added this out of paranoia. makes you think.
I wanted to add the following mount options in the future: inline_data,inline_dentry. actually, they are already enabled!!! look:
Code: Select all
$ head -1 /proc/mounts
/dev/nvme0n1p3 / f2fs rw,lazytime,noatime,background_gc=on,gc_merge,discard,discard_unit=block,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,barrier,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=strict,compress_algorithm=lz4:3,compress_log_size=2,compress_chksum,compress_mode=fs,atgc,memory=normal,errors=continue 0 0
I also wanted to know the following: you can mount F2FS without passing any options, and I think it sets a bunch of options by itself. are they defaults? if not, where they come from? who decided they are best? best for what? so many mysteries.
