All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Brendan Hide <brendan@swiftspirit.co.za>,
	Martin <m_btrfs@ml1.co.uk>,
	linux-btrfs@vger.kernel.org
Subject: Re: USB memory sticks wear & speed: btrfs vs f2fs?
Date: Tue, 9 Feb 2016 09:59:12 -0500	[thread overview]
Message-ID: <56B9FEC0.8020603@gmail.com> (raw)
In-Reply-To: <56B9F2E2.8010808@swiftspirit.co.za>

On 2016-02-09 09:08, Brendan Hide wrote:
> On 2/9/2016 1:13 PM, Martin wrote:
>> How does btrfs compare to f2fs for use on (128GByte) USB memory sticks?
>>
>> Particularly for wearing out certain storage blocks?
>>
>> Does btrfs heavily use particular storage blocks that will prematurely
>> "wear out"?
>>
>> (That is, could the whole 128GBytes be lost due to one 4kByte block
>> having been re-written excessively too many times due to a fixed
>> repeatedly used filesystem block?)
>>
>> Any other comparisons/thoughts for btrfs vs f2fs?
> Copy-on-write (CoW) designs tend naturally to work well with flash
> media. F2fs is *specifically* designed to work well with flash, whereas
> for btrfs it is a natural consequence of the copy-on-write design. With
> both filesystems, if you randomly generate a 1GB file and delete it 1000
> times, onto a 1TB flash, you are *very* likely to get exactly one write
> to *every* block on the flash (possibly two writes to <1% of the blocks)
> rather than, as would be the case with non-CoW filesystems, 1000 writes
> to a small chunk of blocks.
This goes double if you're using the 'ssd' mount option on BTRFS.  Also, 
the only blocks that are rewritten in place on BTRFS (unless you turn 
off COW) are the superblocks, but all filesystems rewrite those in-place.
>
> I haven't found much reference or comparison information online wrt wear
> leveling - mostly performance benchmarks that don't really address your
> request. Personally I will likely never bother with f2fs unless I
> somehow end up working on a project requiring relatively small storage
> in Flash (as that is what f2fs was designed for).
I would tend to agree, but that's largely because BTRFS is more of a 
known entity for me, and certain features (send/receive in particular) 
are important enough for my usage that I'm willing to take the 
performance hit.  IIRC, F2FS was developed for usage in stuff like 
Android devices and other compact embedded devices, where the FTL may 
not do a good job of wear leveling, so it should work equally well on 
USB flash drives (many of the cheap ones have no wear-leveling at all, 
and even some of the expensive ones have sub-par wear-leveling compared 
to good SSD's).

  reply	other threads:[~2016-02-09 15:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-09 11:13 USB memory sticks wear & speed: btrfs vs f2fs? Martin
2016-02-09 14:08 ` Brendan Hide
2016-02-09 14:59   ` Austin S. Hemmelgarn [this message]
2016-02-09 21:52     ` Kai Krakow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56B9FEC0.8020603@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=brendan@swiftspirit.co.za \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=m_btrfs@ml1.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.