[inotify] but needs kernel support, and needs it enabled.
Unfortunately things like BeFs (experimental) does not even have traditional inodes, so ... you have to look for alternatives.
Eh?
inotifywait has nothing to do with inodes, and in recent versions (
git) uses the
fanotify Linux kernel interface. You definitely want to enable it. It operates on the virtual filesystem level, i.e. kernel internal structures, and not on filesystem structures. That is, it has nothing to do with inodes per se; all it requires is that the filesystem provides
fsids, filesystem-unique identifier for each file and directory object in it.
It does not work on FUSE or remote file systems, because they do not monitor or report changes in the remote filesystem. It is not a limitation of inotify/fanotify; it is a limitation of those file systems.
It is best to think of inotify/fanotify as providing notification of
local syscalls affecting watched files and directories. (Thus, other hosts accessing a shared network mount won't show up, nor will
mmap(),
mremap(),
msync() or modifications via memory mapping.)
And I remember having some problems with inotify on bcachefs, too.
bcachefs is
known to lock up in fsstress (March 2024), so I'd say
bcachefs is still too buggy.
so, best case scenario is with the ext* filesystem family, I guess.
ext2, ext3, ext4, xfs, msdos/fat/vfat, exfat, cramfs should work absolutely fine.
I am not sure about zfs, and for btrfs (especially subvolumes) you'll want to include the recent bugfixes.
If you use nfs, fuse, or an experimental filesystem without inotify/fanotify support, or do not want to use inotify-tools for some reason, you can use a formatted
find command to rescan the filesystem sub-tree at regular intervals, checking for changes in size or modification timestamp; via e.g.
find rootdirs -printf '%T@ %s %p\0' > nul-separated-output-filePersonally, I prefer to write a small POSIX C program using
nftw() to walk the directory tree(s), and a dynamic hash table (keyed on the DBJ Xor hash of the file path) to check for changes at regular intervals. I would use a linked list of hash table entries, something along the lines of
typedef struct entry entry;
struct entry {
struct entry *next;
size_t hash;
off_t size;
struct timespec mtime;
char type;
char generation; // Counter for detecting deletions
char path[];
};
where
generation is incremented by one for each time it is seen by
nftw(), so that after a full pass, deleted files can be detected. The
path element at end contains the full relative path to the file or directory, as a C99 and later flexible array member. (Remember to allocate for and set the path-terminating
NUL '\0' character.)
This kind of scanning can be run at idle priority via
nice -n 19 ionice -t 3 command... . The way Linux machines cache filesystem accesses, as long as there is enough RAM available compared to the number of items in the subtree such scanned, repeated scanning produces surprisingly low I/O and CPU load. (The initial scan is slow and relatively high-load, though, because it loads the filesystem data in memory.)
Home
Help
Search
Login
Register
