On Thu, 14 Aug 2008 10:46:55 +0100
tvrtko.ursulin@sophos.com wrote:

quoted text
> So the whole question is at which point should be performing an async 
> scan. Close seems like a natural point which should be ideal for
> majority of applications, I don't see how any time-based
> lumping/delaying scheme can be better than close?

close isn't the answer just because you can write content to the file
after that (and that's not just theoretical, glibc stdio supports mmap
etc); "dirty" *has* to be the event anyway. It's not impossible to
solve; even say a 1 second rearming delay would avoid 99.9% of the
useless rescans while still making sure everything gets scanned at some
point. Anyway this kind of policy can be done in userspace (and you can
get really fancy there and offer the admin various policies)

quoted text
> 
> > > for the open() case, I would argue that you don't need synchronous
> > > behavior as long as the read() case is synchronous. I can imagine
> > > that open() kicks off an async scan, and if it's done by the time
> > > the first read() happens, no blocking at all happens.
> > 
> > An interesting addition.  Trying to keep these queues of events gets
> > much more complex, but if people really think the open to read race
> > is that important I've always said it wasn't impossible to close.
> 
> This really sounds pretty interesting. Not necessariliy so much as a 
> performance optimisation, because I am not sure there are so many
> programs where first read comes long after the first open, but as
> closing the open-read race. 

there's quite a few programs that open() but never read.
open+fstat is not uncommon as programming pattern for example;
with async-in-open (and then wait or sync in read) we wouldn't have the
big hit caused by the latency for the sync scan.
(I realize this pattern is much more likely to happen on posixy systems
than it is on windows.. one of those differences ;-)


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/