linux-kernel - Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Mar 2007 10:54:36 +0200
From:	Artem Bityutskiy <dedekind@...radead.org>
To:	David Woodhouse <dwmw2@...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 21:36 +0000, David Woodhouse wrote:
> 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.

While I agree with you, I still think decent FTL (a) makes sense and is
(b) difficult.

a. Some people may be satisfied with FTL and enjoy all the block
device-related software, which is huge benefit, although costs you
performance. Yes, FTL moves garbage around, but who cares as long as the
performance fits the system requirements.

b. It is certainly not easy.

But anyway, I agree with what you say, although you seem to be too
assertive.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

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