[lkml]   [2011]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT] Bcache version 12
    On Thu, Sep 15, 2011 at 2:15 PM, Dan Williams <> wrote:
    > On Sun, Sep 11, 2011 at 6:44 PM, Kent Overstreet
    > <> wrote:
    >> On Sun, Sep 11, 2011 at 07:35:56PM -0600, Andreas Dilger wrote:
    >>> On 2011-09-11, at 1:23 PM, Kent Overstreet <> 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

    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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-09-15 23:41    [W:0.024 / U:4.652 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site