Linux-f2fs-devel Archive on lore.kernel.org
 help / color / Atom feed
* [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, back to index

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

Linux-f2fs-devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-f2fs-devel/0 linux-f2fs-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-f2fs-devel linux-f2fs-devel/ https://lore.kernel.org/linux-f2fs-devel \
		linux-f2fs-devel@lists.sourceforge.net linux-f2fs-devel@archiver.kernel.org
	public-inbox-index linux-f2fs-devel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/net.sourceforge.lists.linux-f2fs-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox