Re: fanotify: the fscking all notification system

[Valdis . Kletnieks]

On Tue, 30 Jun 2009 13:26:37 EDT, Eric Paris said:

(Sorry for the late reply...)

> Yes.  Although it going to take just a tiny bit of work from me and you
> are limited in how to use it.
> 
> You'll need to request FAN_OPEN_PERM on the file in question.  When the
> file is opened you will need to bring in all the data and write all that
> data into the file.  There is no mechanism to only bring in a piece of a
> file since you have no way of knowing what exactly the requesting
> process is requesting.   So it's a whole file or nothing type of deal.

That's OK - most current HSM implementations work that way already - if they
archive a file, they write out a little stub that basically says "The data is
on tape 948324, file 3342", and on access, the entire file is retrieved.

The only problem is that when we finally return control to the user program,
we need to have wiped out that stub and replaced it with the user's data.

> Current problems:
> 
> 1) the fd the fanotify listener gets is O_RDONLY.  I think I'll add an
> "f_flags" option which if 0 defaults to O_RDONLY|O_LARGEFILE like we
> have today but which you could use to indicate O_RDWR or O_WRONLY.  We
> currently give O_RDONLY since you can't request O_WR* on files/libraries
> mapped exec, so this won't work for executables.....

Having only O_RDONLY is a show-stopper, because then we can't replace the file
contents before continuing.  For many places, the executables and shared
libraries aren't the problem, so "You can't HSM an executable" as a
semi-permanent restriction isn't too bad.

It's the terabytes of data files that are usually the issue - everything from
4-year-old Word documents to video (actual use case - a transportation safety
group here is instrumenting several hundred tractor-trailers with a dozen
cameras that are all rolling at all times the engine is on. That's a lot of
archival video).  An HSM would want O_RDWR for those - RD so it can check and
see if there's a archival stub present, and then WR to restore the file with.

> 2) Right now you have 5 seconds to answer an fanotify permissions
> request, if you don't get it in 5 seconds you are done and the original
> process gets an allow.  But I have a half finished patch which would
> allow you to delay them infinitely.  As long as you keep them delayed
> you can modify the file they are about to access however you like.

That would work fine.

> You can not rename over the fd you are given, you have to actually copy
> the data into that fd, since the inode behind the fd you got from
> fanotify is the same inode the original process is going to get access
> to after your listener sends an allow.

That's an acceptable restriction as well.

> This sound good to you?  I don't know your details, but I believe that
> fanotify directed mode with access permissions is going to be almost
> exactly what you want....

Yes, it's sounding like it. If that's in mainstream, then I can deploy an HSM
without needing kernel hackery like most do currently.

Attachment: pgp00000.pgp
Description: PGP signature