Hi Didier, On 09/02, Chao Yu wrote: > Hello, > > On 2019/9/2 7:20, Didier Spaier wrote: > > Hello, > > > > I plan to provide a more "newbie friendly" installer for the Slint Linux > > distribution that I maintain.
Cool, very interesting. > > > > It will include an "auto" feature intended for newbies, that will > > partition a whole drive and install filesystems with a minimum of user > > input. It would install ext4 file systems in case of hard drives (but > > the ESP and the Bios Boot partition, that is), or f2fs when > > appropriate, without asking. > > > > I am trying to determine for which kinds of devices f2fs should be > > preferred over ext4 (or maybe xfs, I have yet to choose) > > > > I understand that I should target devices equipped of a NAND flash > > memory and interfaced with a FTL. > > > > I think that nowadays most devices of types eMMC, SSD (both SATA and > > PCIe connected, aka NVMe), SD card and flash drives (aka USB sticks) > > have these characteristics thus are good candidates for f2fs. > > > > Simply put, that loks like "everything but hard drives". > > > > Is this correct? > > I do believe that in those devices, in addition SMR (Shingled Magnetic > Recording) drvier, f2fs can behaves better on performance, but for > conventional > hard driver, I got no evidence to show f2fs will perform better (since I > didn't > do such test on hard driver and never got related report like that). F2FS supports HM-SMR by default. For HDD or HA-SMR, I've seen some performance gains w/ ceph. Of course, it depends on user workload tho, if user generates # of random writes, F2FS can give better throughput, since it's log-structured file system. OTHO, if user wants to read out lots of file's data randomly, it'd be better to use conventional disk-based filesystems, since it originally allocated blocks to avoid disk seek time as much as possible. > > > > If yes, I could just check the value of > > /sys/block/<device name>/queue/rotational or the ROTA field of lsblk. > > > > However, I understand that not all flash drives and SSD are based on > > NAND and not all these devices interfaced through a NTL. > > > > Thus my questions are: > > 1. Is the assumption "all devices but hards disks" are potential > > candidate for using f2fs valid? I may be able to say "all devices for laptop", and "flash storages and SMR drives for desktop/server". > > I'm okay with that assumption by default. :) > > > 2. If this assumption is not valid, what are the drawbacks using f2fs > > for all, in terms of performances and security? F2FS now supports fscrypt and will support fsverity, hardware inline encryption, and per-file compression. :) > > 3. Is there a way to tell for a given device if it would benefit of > > using f2fs, that could be implemented in a distribution installer, > > without human intervention? > > IMO, flash based device can be benefit from aspects of: > - better random write performance (inherit gene's advantage from LFS > architecture) > - well SQLite performance (SQLite has started to support to use f2fs atomic > write interface officially in its persist mode) > - recoverable performance (background GC) > - longevity (less writes) > - less performance regression during handling discard command (tuned async > discard policy) Good summary. :P > > > > > Thanks for any clue. and if this is the wrong list for such questions, > > please tell me where I should ask them. > > > > Best regards, > > > > Didier > > > > PS I ship currently a kernel 4.19.x. Is this OK? > > I'm okay with that. > > Also I recommend to use our private stable tree below in where we backport > most > upstreamed codes, and the codes in that stable tree are used on Android now. > > https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-stable.git/ Side note: this will provide all the f2fs/fscrypt backports to android common kernel. It'd be great to sync this with your distro kernel as much as possible. > > BTW please note that: > - DON'T try corrupted feature via mkfs.f2fs -i with the version <= 1.12.0. > - tune overprivsion rate with a proper value to avoid performance regression > when there is no more space in the device. > > > > > > > _______________________________________________ > > Linux-f2fs-devel mailing list > > Linux-f2fs-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > . > > > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
