| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 02 Apr 2009 19:15:37 +0200 From: Alexander Larsson <alexl@...hat.com> To: Jan Kara <jack@...e.cz> Cc: eparis@...hat.com, linux-kernel@...r.kernel.org Subject: Re: Issues with using fanotify for a filesystem indexer On Thu, 2009-04-02 at 18:50 +0200, Jan Kara wrote: > On Thu 02-04-09 18:29:04, Alexander Larsson wrote: > > Another potential issue with this is that every change bubbles up to the > > top, modifying the recursive mtime of that. This will become very > > contented, and may imply a partial serialization of fs activity, which > > is kinda costly. > Not every change - only the first change bubbles to the top, clearing the > flag on its way. Then next change stops bubbling up as soon as it reaches > a directory with the flag cleared. So no contention happen - we update flag > + timestamp only at most once per scan of the directory by indexer (or > someone else interested in recursive mtime) => once per a few minutes on > average system. Ah, I see. The indexer sets the flag. I see some issues. First of all, writing the flag/mtime to disk seems like a bad idea. It'll cause a lot of writing when the indexer recurses throught the filesystem, similar to atimes. But, if you're not persisting the flag/mtime then you need to keep all the dentries with the flag set in memory, which has resource use risks similar to unbounded event queues. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists