grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] F2FS support


From: Adam Borowski
Subject: Re: [PATCH] F2FS support
Date: Thu, 4 May 2017 22:52:09 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Thu, May 04, 2017 at 11:12:40AM -0700, Jaegeuk Kim wrote:
> "F2FS (Flash-Friendly File System) is flash-friendly file system which was 
> merged
> into Linux kernel v3.8 in 2013.
> 
> The motive for F2FS was to build a file system that from the start, takes into
> account the characteristics of NAND flash memory-based storage devices (such 
> as
> solid-state disks, eMMC, and SD cards).

Some reason "why?" would be nice.

Here's a rough comparison, class 4 SD card on a Pine64, median of 5:
* "git reset --hard" in a big empty tree:
  btrfs 3m45s, f2fs 4m, ext4 12m, xfs 16-18m (huge variance)
* "./configure && make -j4 && make test" (highly CPU-bound)
  f2fs 95s, btrfs 97s, xfs 120s, ext4 122s
* linear write of a single big file
  no meaningful differences

Ie, there's a drastic gain for using f2fs or btrfs.  But btrfs is... well,
btrfs.  It has both significant data safety features and "WTF" level caveats
that can result in abysmal performance, unexpected lack of space or even
data loss when handled by a naive user in ways that are perfectly safe for
most other filesystems.  Thus, it'd be irresponsible to unleash btrfs onto
an unprepared user.  Which leaves f2fs which works well with "install and
forget".

And there's a bunch of new machines that boot from SD/eMMC even on x86.


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]