| 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
| ||
|
Message-ID: <CAC7rs0t_J+foaLZSuuw5BhpUAYfr-KY1iegFOxEBPCpbrkk1Dg@mail.gmail.com> Date: Thu, 15 Sep 2011 14:33:36 -0700 From: Kent Overstreet <kent.overstreet@...il.com> To: Dan Williams <dan.j.williams@...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 Thu, Sep 15, 2011 at 2:15 PM, Dan Williams <dan.j.williams@...il.com> wrote: > 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()? Damn, nope. I still think a module parameter is even uglier than a sysfs file, though. As far as I can tell, the linux kernel is really lacking any sort of coherent vision for how to make arbitrary interfaces available from the filesystem. We all seem to agree that it's a worthwhile thing to do - nobody likes ioctls, /proc/sys has been around for ages; something visible and discoverable beats an ioctl or a weird special purpose system call any day. But until people can agree on - hell, even come up with a decent plan - for the right way to put interfaces in the filesystem, I'm not going to lose much sleep over it. >> 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. I did spend some time looking at md, I don't really remember if I gave it a fair chance or if I found a critical flaw. I agree that an md personality ought to be a good fit but I don't think the current md code is ideal for what bcache wants to do. Much saner than dm, but I think it still suffers from the assumption that there's some easy mapping from superblocks to block devices, with bcache they really can't be tied together. > And md supports assembling devices via sysfs without > requiring mdadm which is a nice feature. Didn't know that, I'll have to look at that. If nothing else consistency is good... > 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. Dunno what you mean about external metadata, but it would be nice to not have to do anything to userspace to boot from a bcache device. As is though it's only a couple lines of bash you have to drop in your initramfs. -- 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