* [f2fs-dev] Which kind of devices would benefit of f2fs? @ 2019-09-01 23:20 Didier Spaier 2019-09-02 6:38 ` Chao Yu 0 siblings, 1 reply; 3+ messages in thread From: Didier Spaier @ 2019-09-01 23:20 UTC (permalink / raw) To: linux-f2fs-devel 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? 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? 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? 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? _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [f2fs-dev] Which kind of devices would benefit of f2fs? 2019-09-01 23:20 [f2fs-dev] Which kind of devices would benefit of f2fs? Didier Spaier @ 2019-09-02 6:38 ` Chao Yu 2019-09-02 23:28 ` Jaegeuk Kim 0 siblings, 1 reply; 3+ messages in thread From: Chao Yu @ 2019-09-02 6:38 UTC (permalink / raw) To: Didier Spaier, linux-f2fs-devel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [f2fs-dev] Which kind of devices would benefit of f2fs? 2019-09-02 6:38 ` Chao Yu @ 2019-09-02 23:28 ` Jaegeuk Kim 0 siblings, 0 replies; 3+ messages in thread From: Jaegeuk Kim @ 2019-09-02 23:28 UTC (permalink / raw) To: Chao Yu; +Cc: linux-f2fs-devel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-09-02 23:28 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-01 23:20 [f2fs-dev] Which kind of devices would benefit of f2fs? Didier Spaier 2019-09-02 6:38 ` Chao Yu 2019-09-02 23:28 ` Jaegeuk Kim
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).