linux-kernel - Re: [GIT] Bcache version 12

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:	Thu, 15 Sep 2011 14:15:19 -0700
From:	Dan Williams <dan.j.williams@...il.com>
To:	Kent Overstreet <kent.overstreet@...il.com>
Cc:	Andreas Dilger <adilger@...ger.ca>, NeilBrown <neilb@...e.de>,
	"linux-bcache@...r.kernel.org" <linux-bcache@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"rdunlap@...otime.net" <rdunlap@...otime.net>,
	"axboe@...nel.dk" <axboe@...nel.dk>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [GIT] Bcache version 12

On Sun, Sep 11, 2011 at 6:44 PM, Kent Overstreet
<kent.overstreet@...il.com> wrote:
> On Sun, Sep 11, 2011 at 07:35:56PM -0600, Andreas Dilger wrote:
>> On 2011-09-11, at 1:23 PM, Kent Overstreet <kent.overstreet@...il.com> wrote:
>> > I don't think that makes any more sense, as module paramaters AFAIK are
>> > even more explicitly just a value you can stick in and pull out.
>> > /sys/fs/bcache/register is really more analagous to mount().

... and you looked at module_param_call()?

>> > You're not the first person to complain about that, I moved it to
>> > configfs for awhile at Greg K-H's behest... but when I added cache sets
>> > I had to move it back to sysfs.
>> >
>> >> Alternately you could device a new 'bus' type for bcache and do some sort of
>> >> device-model magic to attach something as a new device of that type.
>> >
>> > I like that, I think that could make a lot of sense.
>> >
>> > I'm not sure what to do about register though, I do prefer to have it a
>> > file you can echo to but it doesn't really fit anywhere.
>>
>> Rather than using /proc or /sys to configure bcache, why not integrate it with device mapper, and use dmsetup to configure it?  That avoids adding yet another block device abstraction into the kernel, and yet one more obscure way of configuring things.
>>
>> A bcache device could be considered almost like an LV snapshot, where writes go to the SSD device instead of a disk, and they can have writeback or writethrough cache.
>
> I looked into that many months ago, spent quite a bit of time fighting
> with the dm code trying to get it to do what I wanted and... no. Never
> again

Did you do a similar analysis of md?  I had a pet caching project that
had it's own sysfs interface registration system, and came to the
conclusion that it would have been better to have started with an MD
personality.  Especially when one of the legs of the cache is a
md-raid array it helps to keep all that assembly logic using the same
interface.  And md supports assembling devices via sysfs without
requiring mdadm which is a nice feature.

Also has the benefit of reusing the distro installation / boot
enabling for md devices which turned out to be a bit of work when
enabling external-metadata in md.

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