linux-ext4 - Re: bcache with existing ext4 filesystem

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: <20170725220221.GA32240@amd>
Date:   Wed, 26 Jul 2017 00:02:22 +0200
From:   Pavel Machek <pavel@....cz>
To:     Eric Wheeler <bcache@...ts.ewheeler.net>
Cc:     Vojtech Pavlik <vojtech@....cz>, Theodore Ts'o <tytso@....edu>,
        Reindl Harald <h.reindl@...lounge.net>,
        linux-ext4@...r.kernel.org,
        kernel list <linux-kernel@...r.kernel.org>,
        kent.overstreet@...il.com, linux-bcache@...r.kernel.org
Subject: Re: bcache with existing ext4 filesystem

Hi!

> > > > Unfortunately, that would mean shifting 400GB data 8KB forward, and
> > > > compatibility problems. So I'd prefer adding bcache superblock into
> > > > the reserved space, so I can have caching _and_ compatibility with
> > > > grub2 etc (and avoid 400GB move):
> > > 
> > > The common way to do that is to move the beginning of the partition,
> > > assuming your ext4 lives in a partition.
> > 
> > Well... if I move the partition, grub2 (etc) will be unable to access
> > data on it. (Plus I do not have free space before some of the
> > partitions I'd like to be cached).
> 
> Why not use dm-linear and prepend space for the bcache superblock?  If 
> this is your boot device, then you would need to write a custom 
> initrd hook too.

Thanks for a pointer. That would actually work, but I'd have to be
very, very careful using it...

...because if I, or systemd or some kind of automounter sees the
underlying device (sda4) and writes to it (it is valid ext4 after
all), I'll have inconsistent base device and cache ... and that will
be asking for major problems (even in writethrough mode).

Actually, this already would be usable, if we killed content of cache
device on every mount. Hmmm. I have reasonably long uptimes these days.

If possible, I'd like something more clever: bcache saves mtime of the
ext4 filesystem on shutdown. If the mtime does not match on the next
startup, it means someone fsck-ed the filesystem or mounted it
directly or something, and cache is invalid.

Bonus would be some kind of interlock with "incompatible feature"
bits. If the bcache has dirty data in write-back cache, it would be
nice to have "incompatible feature" bit set, so that tools that don't
have access to the cache refuse to touch it.

Best regards,

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)