USB memory sticks wear & speed: btrfs vs f2fs?

[Martin]

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?


Thanks for any comment,
Martin

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB memory sticks wear & speed: btrfs vs f2fs?

[Brendan Hide]

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.


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


If someone can provide or link to some proper comparison data, that 
would be nice. :)


--
__
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB memory sticks wear & speed: btrfs vs f2fs?

[Austin S. Hemmelgarn]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB memory sticks wear & speed: btrfs vs f2fs?

[Kai Krakow]

Am Tue, 9 Feb 2016 09:59:12 -0500
schrieb "Austin S. Hemmelgarn" :

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html