Subject: Re: Issues with using fanotify for a filesystem indexer
From: Alexander Larsson <alexl@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: eparis@redhat.com, linux-kernel@vger.kernel.org
In-Reply-To: <20090402195253.GH3010@duck.suse.cz>
References: <1238158043.23703.20.camel@fatty>
	 <20090402145457.GA17275@atrey.karlin.mff.cuni.cz>
	 <1238689744.5704.1.camel@localhost.localdomain>
	 <20090402165023.GG3010@duck.suse.cz>
	 <1238692537.5704.6.camel@localhost.localdomain>
	 <20090402195253.GH3010@duck.suse.cz>
Content-Type: text/plain
Date: Fri, 03 Apr 2009 08:44:03 +0200
Message-Id: <1238741043.31635.2.camel@fatty>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1425
Lines: 31

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/