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]

Message-ID: <20070321113523.GD3785@lazybastard.org>
Date:	Wed, 21 Mar 2007 12:35:23 +0100
From:	Jörn Engel <joern@...ybastard.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Matt Mackall <mpm@...enic.com>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
	Artem Bityutskiy <dedekind@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Frank Haverkamp <haver@...t.ibm.com>,
	Christoph Hellwig <hch@...radead.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images

On Wed, 21 March 2007 12:25:34 +0100, Thomas Gleixner wrote:
> On Wed, 2007-03-21 at 12:05 +0100, Jörn Engel wrote:
> > 
> > Ok, now we have reached the absurd.  UBI quite fundamentally cannot do
> > wear leveling as good as LogFS can.  Simply because UBI has zero
> > knowledge of the _contents_ of its blocks.  Knowing whether a block is
> > 90% garbage or not makes a great difference.
> > 
> > Also LogFS currently requires erasesizes of 2^n.
> 
> Last time I talked to you about that, you said it would be possible and
> fixable. We talked about several mechanisms, which would allow a
> filesystem or other users to hint such things to UBI.

Note the word "currently".  And yes, we did talk about hints.  Back then
I still believed in UBI.  That has changed and I would like to spare
myself another flamewar, so please leave it at that.

> Even if the LogFS wear levelling is so superior, it CAN'T do across
> device wear levelling.

Correct.  And I don't see any problem with this.  I see two classes of
usecases for flash, with some amount of overlap in between.

1. Small amounts of flash.

Here the flash contains a large ratio of read-only data.  Bootloader,
kernel, etc.  Having wear levelling across the device will gain you
something.  This is what you designed UBI for.

2. Large amounts of flash.

Just to be precise, large can go well into the Terabyte range and
beyond.  I don't mean large as in "the biggest embedded device I worked
on last year" - that is still small.

Even if such flashes still contain a bootloader and a kernel, that will
occupy less than 1% of the device.  Wear leveling across the device is
fairly pointless here.  This is what I designed LogFS for.

There is some middle ground where a combination of UBI and LogFS may
make sense.  LogFS can still make sense for devices as small as 64MiB.
But I'm not too concerned about that because flashes will continue to
grow and the advantages of cross-device wear leveling will continue to
diminish.

Jörn

-- 
"Security vulnerabilities are here to stay."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001
-
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/