[gentoo-user] Re: Re: [Gentoo-User] emerge --sync likely to kill SSD?

[Kai Krakow]

Rich Freeman <rich0@g.o> schrieb:

> On Sat, Jun 21, 2014 at 10:27 AM, Peter Humphrey <peter@××××××××××××.uk>
> wrote:
>>
>> I found that fstrim can't work on f2fs file systems. I don't know whether
>> discard works yet.
>
> Fstrim is to be preferred over discard in general.  However, I suspect
> neither is needed for something like f2fs.  Being log-based it doesn't
> really overwrite data in place.  I suspect that it waits until an
> entire region of the disk is unused and then it TRIMs the whole
> region.

F2fs prefers to fill an entire erase block before touching the next. It also 
tries to coalese small writes into 16k blocks before submitting them to 
disk. And according to the docs it supports trim/discard internally.

> However, I haven't actually used it and only know the little I've read
> about it.  That is the principle of a log-based filesystem.

There's an article at LWN [1] and in the comments you can find a few 
important information about the technical details.

Posted Oct 11, 2012 21:11 UTC (Thu) by arnd:
| * Wear leveling usually works by having a pool of available erase blocks
|   in the drive. When you write to a new location, the drive takes on block
|   out of that pool and writes the data there. When the drive thinks you
|   are done writing to one block, it cleans up any partially written data
|   and puts a different block back into the pool.
| * f2fs tries to group writes into larger operations of at least page size
|   (16KB or more) to be efficient, current FTLs are horribly bad at 4KB
|   page size writes. It also tries to fill erase blocks (multiples of 2MB)
|   in the order that the devices can handle.
| * logfs actually works on block devices but hasn't been actively worked on
|   over the last few years. f2fs also promises better performance by using
|   only 6 erase blocks concurrently rather than 12 in the case of logfs. A
|   lot of the underlying principles are the same though.
| * The "industry" is moving away from raw flash interfaces towards eMMC and
|   related technologies (UFS, SD, ...). We are not going back to raw flash
|   any time soon, which is unfortunate for a number of reasons but also has
|   a few significant advantages. Having the FTL take care of bad block
|   management and wear leveling is one such advantage, at least if they get
|   it right.

According to wikipedia [2], some more interesting features are on the way, 
like compression and data deduplication to lower the impact of writes.
 
[1]: http://lwn.net/Articles/518988/
[2]: http://en.wikipedia.org/wiki/F2FS

-- 
Replies to list only preferred.