|
|
Log in / Subscribe / Register

Superblock watch for fsnotify

By Jake Edge
April 5, 2017

LSFMM 2017

At the 2017 Linux Storage, Filesystem, and Memory-Management Summit, Amir Goldstein led a discussion about the fsnotify filesystem notification subsystem and some changes he would like to see. Unfortunately, due to a bit of confusion of where the session would be held, I missed half of it; here's what I can reconstruct from the second half. Fsnotify is the internal kernel support subsystem for all three of the file notification APIs (dnotify, inotify, and fanotify).

Goldstein is trying to make fsnotify more scalable for getting notifications of changes in a large filesystem. To that end, he has proposed a "superblock watch" mechanism to efficiently report all changes made to a filesystem. For his use case, he just needs to be able to receive notifications when any file in any directory in the filesystem has changed (been created, deleted, or moved). There was a question about whether the names of the files that are changed should be included in the event, but Goldstein said he did not need that functionality (though others might); his application simply rescans the directory if anything has changed in it.

Al Viro was concerned that the file names would not stay valid while notifications were being delivered. Jan Kara said that there could be races that would make it hard to reproduce the sequence of changes that were made to the directory. But adding names to the fsnotify events does add significant complexity to the code. There is a clear demand for being able to get notification events on a large directory tree, however, Kara said. For now, he is not convinced that adding file names into the event is warranted and it could lead to various kinds of problems.

Goldstein said that the superblock watch is the simplest approach, rather than having a recursive fanotify watch on the mount point, which does not scale well. That API could eventually be extended to allow the creation of a change journal like NTFS supports, he said. There did not seem to be any fundamental opposition to the superblock watch feature as it stands.


Index entries for this article
Kernelfanotify
ConferenceStorage, Filesystem, and Memory-Management Summit/2017


to post comments

Superblock watch for fsnotify

Posted Apr 6, 2017 8:29 UTC (Thu) by Sesse (subscriber, #53779) [Link] (2 responses)

Potentially useful for incremental backups, assuming one can guard against lost events?

Superblock watch for fsnotify

Posted Apr 6, 2017 10:44 UTC (Thu) by amir73il (subscriber, #66165) [Link] (1 responses)

Incremental backup/sync is the use case I am working on. Full protection against lost events can only be done with file system level support (like NTFS has)

Superblock watch for fsnotify

Posted Apr 6, 2017 10:51 UTC (Thu) by Sesse (subscriber, #53779) [Link]

I always wanted something like a bloom filter, where you could statically allocate a chunk of memory up-front and thus never have to worry about failing inserts (nor locking for them). Your backup software could then just ask the bloom filter (with 0% chance of false negatives and e.g. 1% chance of false positives) whether a directory was worth scanning for changes or not.

(E.g., if you changed /foo/bar/baz, the bloom filter would see inserts for /, /foo/, and /foo/bar. If nothing else was inserted, you wouldn't have to scan into /home or /usr at all.)

/* Steinar */


Copyright © 2017, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds