linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kai Krakow <hurikhan77@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: USB memory sticks wear & speed: btrfs vs f2fs?
Date: Tue, 9 Feb 2016 22:52:04 +0100	[thread overview]
Message-ID: <20160209225204.13f9ffbc@jupiter.sol.kaishome.de> (raw)
In-Reply-To: 56B9FEC0.8020603@gmail.com

Am Tue, 9 Feb 2016 09:59:12 -0500
schrieb "Austin S. Hemmelgarn" <ahferroin7@gmail.com>:

> > 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).

Actually, I think most of them only do wear-levelling in the storage
area where the FAT is expected - making them pretty useless for
anything else than FAT formatting...

I think the expected use-case for USB flash drives is only adding
files, and occasionally delete them - or just delete all / reformat.
It's not expected to actually "work" with files on such drives. Most of
them are pretty bad at performance anyways for such usage patterns.
It's actually pretty easy to wear out such a drive within a few days.
I've tried myself with a drive called "ReadyBoost-capable" - yeah, it
took me 2 weeks to wear it out after activating "ReadyBoost" on it, and
it took only a few days to make its performance crawl. It's just slow
now and full of unusable blocks.

-- 
Regards,
Kai

Replies to list-only preferred.


      reply	other threads:[~2016-02-09 21:54 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
2016-02-09 21:52     ` Kai Krakow [this message]

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=20160209225204.13f9ffbc@jupiter.sol.kaishome.de \
    --to=hurikhan77@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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 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).