Re: [PATCH] LogFS take three

["Dongjun Shin" <djshin90@gmail.com>]

On 5/17/07, David Woodhouse <dwmw2@infradead.org> wrote:
> Yes. These things are almost always implemented _very_ badly by the same
> kind of crack-smoking hobo they drag in off the streets to write BIOSen.
>
> It's bog-roll technology; if you fancy a laugh try doing some real
> reliability tests on them time some. Powerfail testing is a good one.
>
> This kind of thing is OK for disposable storage such as in digital
> cameras, where it doesn't matter that it's no more reliable than a
> floppy disc, but for real long-term storage it's really a bad idea.

There are so many flash-based storage and some disposable storages,
as you pointed out, have poor quality. I think it's mainly because these
are not designed for good quality, but for lowering the price.

These kind of devices are not ready for things like power failure because
their use case is far from that. For example, removing flash card
while taking pictures using digital camera is not a common use case.
(there should be a written notice that this kind of action is against
the warranty)

> There's little point in optimising a file system _specifically_ for
> devices which in often aren't reliable enough to keep your data anyway.
> You might as well use ramfs.
>
> It's unfortunate really -- there's no _fundamental_ reason why FTL has
> to be done so badly; it's just that it almost always is. Direct access
> to the flash from Linux is _always_ going to be better in practice --
> and that way you avoid the problems with dual journalling, along with
> the problems with the underlying FTL continuing to keep (and copy around
> during GC) sectors which the top-level filesystem has actually
> deallocated, etc.

There are, of course, cases where direct access are better.
However, as the demand for capacity, reliability and high performance
for the flash storage increases, the use of FTL with embedded controller
would be inevitable.

- The complexity/cost of host-side SW (like JFFS2/MTD) will increase due to
the use of multiple flash in parallel and the use of high degree ECC algorithm.
There are other things like bad block handling and wear-leveling issues
which has been recently touched by UBI with added SW complexity.

- In contrast to the embedded environment where CPU and flash is directly
connected, the I/O path between CPU and flash in PC environment is longer.
The latency for SW handshaking between CPU and flash will also be longer,
which would make the performance optimization harder.

As I mentioned, some techniques like log-structured filesystem could
perform generally better on any kind of flash-based storage with FTL.
Although there are many kinds of FTL, it is commonly true that
it performs well under workload where sequential write is dominant.

I also expect that FTL for PC environment will have better quality spec
than the disposable storage.

Dongjun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/