Messages in this thread |  | | | From | Bryan Donlan <> | | Date | Tue, 30 Jun 2009 13:13:08 -0400 | | Subject | Re: fanotify: the fscking all notification system |
| |
On Tue, Jun 30, 2009 at 9:22 AM, <Valdis.Kletnieks@vt.edu> wrote: > On Mon, 29 Jun 2009 16:08:45 EDT, Eric Paris said: > >> fanotify provides two things: >> 1) a new notification system, sorta like inotify, only instead of an >> arbitrary 'watch descriptor' which userspace has to know how to map back >> to an object on the filesystem, fanotify provides an open read-only fd >> back to the original object. It should be noted that the set of >> fanotify events is much smaller than the set of inotify events. >> >> 2) an access system in which processes may be blocked until the fanotify >> userspace listener has decided if the operation should be allowed. > > I don't care much about virus scanners - but some of us with petabytes of > disk space to manage could use tis for HSM applications. The HSM daemon > could fanotify on the file, notice that the file accessed referred to a > special "I've been archived" stub/token, and put the file back before > giving the go-ahead to the process. > > The only sticky question - does this happen early enough that the accessing > process, when un-blocked, will continue through open() and get the *new* > version of the newly restored file? >
In that particular case, why not just make it a sparse file (so the size fields in stat are correct), and put back the original data in the very same inode? -- 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/
|  |