Hi Arno, wt., 28 kwi 2026 o 22:36 Arno Lehmann via Bacula-users < [email protected]> napisał(a):
> > Commvault uses a similar technique. So that's how I know it is > > beneficial and feasible. =) > > Well, Commvault has years of engineering and a rather large team of > developers working on those things, which I like to understand as > justifying my doubts :-) > Please keep in mind that all commercial vendors need to differentiate their own product among competitors. So, the race is: do you have this functionality or not? When you will carefully study all the functionality available in different products you will find some of them are simply useless but allow marketing teams to shine. :) > But as I said -- I'd really like to give your product a try. There are > quite some aspects that the public documenttaion does not cover -- for > example, what will happen if the Sentinel Plugin gets incomplete file > change history, or gets swamped with change notifications? How will it > work with uncommon file systems, and what happens if backups are too > rare so the list of changed files overflows? > The idea of an "incremental accelerator" for common local filesystems is great. But the inotify api is not the best solution for this case IMVHO, YMMV. The main issue is the scalability issue. You want to use "incremental accelerator" for all your high volume storage, but inotify functionality does not scale. The more directories you want to inotify the more resources it requires. A tradeoff, sure. I did a prototype of this feature years ago (no coding LLM existed yet) and it wasn't worth the effort (the architecture was different, when fd starts it spawns a special thread and registers required watches from the config file, so incremental job can ask this thread what changed - it was a never ending story of issues, race conditions, edge cases, etc.). Today there is a modern and scalable fanotify API (or FSEvents in macOS or USN Change Journal in win) which should be used instead, again IMVHO, YMMV. best regards -- Radosław Korzeniewski [email protected]
_______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
