lkml.org 
[lkml]   [2010]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.36-rc7
>>>>> "Eric" == Eric Paris <eparis@redhat.com> 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
are.

Thanks,
John


\
 
 \ /
  Last update: 2010-10-07 23:19    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site