[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19056257.kzSp6roqV4@deuteros>
Date: Wed, 14 Nov 2012 09:50:55 +0000
From: Tvrtko Ursulin <tvrtko.ursulin@...lan.co.uk>
To: Cyrill Gorcunov <gorcunov@...nvz.org>
Cc: David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Al Viro <viro@...iv.linux.org.uk>,
Alexey Dobriyan <adobriyan@...il.com>,
Pavel Emelyanov <xemul@...allels.com>,
James Bottomley <jbottomley@...allels.com>,
Matthew Helsley <matt.helsley@...il.com>,
aneesh.kumar@...ux.vnet.ibm.com, bfields@...ldses.org
Subject: Re: [patch 3/7] fs, notify: Add file handle entry into inotify_inode_mark
On Wednesday 14 November 2012 13:38:49 Cyrill Gorcunov wrote:
> On Wed, Nov 14, 2012 at 09:20:51AM +0000, Tvrtko Ursulin wrote:
> > On Tuesday 13 November 2012 19:28:46 Cyrill Gorcunov wrote:
> > > On Tue, Nov 13, 2012 at 03:02:22PM +0000, Tvrtko Ursulin wrote:
> > > > Perhaps there could be a different way, where you could use additional
> > > > space only when it is actually used at runtime. But as I said, I am
> > > > not
> > > > following closely.
> > >
> > > Unfortunatelly at moment I see no way how to make it in on-demand
> > > fashion.
> >
> > You could not use a pointer and then allocate your buffers on the check
> > point operation, freeing on restore?
>
> The problem is not allocating the memory itself but rather the time when the
> information needed (ie the dentry) is available. The only moment when we
> can use dentry of the target file/directory is at inotify_new_watch, that's
> why i need to compose fhandle that early. At any later point we simply have
> no dentry to use.
But you do not fundamentally need the dentry to restore a watch, right?
Couldn't you restore, creating a new restore path if needed, using the inode
which is pinned anyway while the watch exists?
Regards,
Tvrtko
--
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