[lkml]   [2010]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux 2.6.36-rc7
    >>>>> "Eric" == Eric Paris <> writes:

    Eric> On Thu, 2010-10-07 at 18:15 +0100, Tvrtko Ursulin wrote:
    >> On Thursday 07 Oct 2010 17:10:46 Tvrtko Ursulin wrote:
    >> > On Wednesday 06 Oct 2010 22:45:13 Linus Torvalds wrote:

    >> Priority argument was dropped from the fanotify_init syscall, and since it is
    >> a syscall once released it is set in stone. Without the priority argument, how
    >> are multiple clients supposed to be ordered?
    >> Co-existence between multiple clients was something which was supposed to be
    >> designed in from the start. Use cases like hierarchical storage management,
    >> anti-malware and content indexing should all be able to co-exist. Without a
    >> priority argument I do not see how it can be assured HSM sees the perm event
    >> before anti-malware, and content indexing after both of them? If there was any
    >> discussion about dropping priority I missed it. :(

    Eric> Shit. I'm trying to remember the logic. hrmph.... You could
    Eric> have a real interface issue.... Shit. Let me think about it
    Eric> for an hour or two.

    Eric> Original idea of priorities was to allow multiple permissions
    Eric> decision makers to co-exist without having the livelock problem
    Eric> of each trying to grant and deny access to each other. That was
    Eric> solved with the O_NONOTIFY hack and I think the priority was
    Eric> then thought to be useless. But you're absolutely right, it
    Eric> isn't useless if we consider that an HSM might need to run first
    Eric> to make sure data exists on disk before an indexer looks at the
    Eric> data.

    Eric> I see two possibilities off the top of my head:

    Eric> I could just slap an (unused) priority field onto the end of the
    Eric> fanotify_init() syscall (assuming Linus doesn't murder me) so we
    Eric> can build that support out with explicit priorities down the
    Eric> line, which I think might be overkill, or

    Eric> The other option (without breaking ABI as it stands today) is to
    Eric> define some set of the fanotify_init() flags to be a priority
    Eric> field, we've got 32 bits and only use 2 of them so giving 4-8
    Eric> bits of that as a priority (next cycle) isn't an issue and can
    Eric> be easily backwards compatible.

    So what happens when you try to register a priority level and someone
    else has already gotten that level? Does the call fail? Do you get
    bumped down to the next open level? Can you *tell* what level you're
    at and whether or not some other decision maker is ahead of you?

    So if I register an HSM module for /home, with a priority of 1, and
    then register a content indexer for /home/john at priority 1, will
    they clash? Who wins? The one registered first?

    I tried looking in Documentation/fs/fanotify.txt but I couldn't find
    it anywhere. So I had to grep around looking for the file which held
    fanotify_init() so I could look it over... and then my brain started
    bleeding from the lack of any comments on the various functions on WTF
    they were supposed to do.

    But hey, I admit I'm not a kernel programmer at all, nor a low level
    FS guy, so I probably just don't have the indepth understanding of
    Linux kernel internals. I just need to spend six months hacking on
    the code to come upto speed.

    But I'd really like some docs in the next release which tells me as a
    poor dumb sysadmin how it can and should be used and what the gotchas


     \ /
      Last update: 2010-10-07 23:19    [W:0.048 / U:26.540 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site