[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1174426591.20505.20.camel@pmac.infradead.org>
Date: Tue, 20 Mar 2007 21:36:31 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: dedekind@...radead.org
Cc: David Lang <david.lang@...italinsight.com>,
Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
Theodore Tso <tytso@....edu>, Matt Mackall <mpm@...enic.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Frank Haverkamp <haver@...t.ibm.com>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images
On Tue, 2007-03-20 at 22:05 +0200, Artem Bityutskiy wrote:
> Guess why we still do not have a decent FTL? Because it is
> _difficult_.
No. We don't have a decent FTL because it's _pointless_. We've got basic
implementations of FTL, NFTL, INFTL etc. for compatibility with PCMCIA
stuff and DiskOnChip, but the fact remains that pretending to be a
normal block device with atomically-overwritten 512-byte sectors is just
_stupid_. You end up implementing a kind of pseudo-filesystem to do
that, and then on top of that you put a 'normal' filesystem with no real
knowledge about what's underneath. It's crap -- and as we currently have
it, the top level file system doesn't even get to tell the underlying
FTL that a given block can be discarded because it's no longer used. So
during garbage collection the FTL even ends up copying crap around the
medium that's no longer relevant.
This isn't DOS. We don't have to make our storage available through the
restricted interface that INT 13h offers us. We can, and do, do better
than that. And that's why we don't have a decent FTL implementation.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists