[lkml]   [2009]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] ocfs2 changes for 2.6.32

    On Fri, 11 Sep 2009, Joel Becker wrote:
    > Linus, et al,
    > Here are the ocfs2 feature changes for 2.6.32. The big ticket
    > item is the reflinkat(2) system call and ocfs2's support for it. The
    > ocfs2 support accounts for all but a handful of the changes. The
    > remaining few patches are fixes.

    I _really_ want some kind of ack's for new filesystem system calls like
    this. I'm not going to pull a new 'reflink[at]()' system call just based
    on a single filesystem.

    Yes, there's clearly been _some_ discussion, but (a) I've not seen it
    (since it's been on 'fsdevel', which is one of those single-topic mailing
    lists that I'm totally uninterested in, since they tend to become clique
    groups) and (b) you don't even say whether the thing has been acked by
    things like the security angle etc.

    So I'm not pulling this. Not until I get the feeling that there is

    I also don't understand why it's called 'reflink'. Why not 'copyfile'? We
    should not name things by implementation, we should name things by what
    they _do_. And I'm not seeing what is so 'reflink' about this that it's
    not a 'copyfile'. I also am not entirely clear on why you need the source
    name, and not - for example - an 'fd'.

    Are we going to add 'freflink[at]()' at some point?

    So I want explanations for the naming, I want sign-offs from other
    filesystem (and security) people, etc. What I do _not_ want is to get a
    "please pull" request for a filesystem, and notice that it's suddenly not
    all about just that particular filesystem, without any indication of who
    you've been talking to etc etc.


     \ /
      Last update: 2009-10-18 23:28    [W:0.021 / U:3.532 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site