linux-kernel - Re: Issues with using fanotify for a filesystem indexer

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1238741043.31635.2.camel@fatty>
Date:	Fri, 03 Apr 2009 08:44:03 +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 21:52 +0200, Jan Kara wrote:
> On Thu 02-04-09 19:15:37, Alexander Larsson wrote:
> > 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
>
>   There's some cost but it's not nearly as bad as with atimes. 

True, its not as bad as atimes. But it still does some writes, and
writes seem to affect i/o performance more than low prio reads from the
indexer. I'm very wary about the background indexer process disturbing
the foreground processes. This is one of the main problems with current
indexers.

> > 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.
>   Ah, true - I have implemented just the persistent case and have not
> thought too much about the non-persistent one. You're right that it won't
> work because we'd pin memory.

So, where do you persist the flag/time? Is there some availible space in
the inode for it on ext3/4?


--
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/