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. > > 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). > > 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'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? > 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) > > 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/ 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
