On Wed, Nov 14, 2012 at 08:26:22AM -0500, J. Bruce Fields wrote:
> On Wed, Nov 14, 2012 at 05:03:47PM +0400, Cyrill Gorcunov wrote:
> > On Wed, Nov 14, 2012 at 07:45:49AM -0500, J. Bruce Fields wrote:
> > > >
> > > > We can try going this route, what do you think?
> > >
> > > I still don't unders
On Wed, Nov 14, 2012 at 05:03:47PM +0400, Cyrill Gorcunov wrote:
> On Wed, Nov 14, 2012 at 07:45:49AM -0500, J. Bruce Fields wrote:
> > >
> > > We can try going this route, what do you think?
> >
> > I still don't understand why you need a dentry to get the filehandle.
> > The current api may ask
On Wed, Nov 14, 2012 at 07:45:49AM -0500, J. Bruce Fields wrote:
> >
> > We can try going this route, what do you think?
>
> I still don't understand why you need a dentry to get the filehandle.
> The current api may ask for one, but it shouldn't really be necessary
> (assuming you don't want par
On Wed, Nov 14, 2012 at 02:46:42PM +0400, Pavel Emelyanov wrote:
> Well, the MAX_HANDLE_SZ is taken from NFSv4 and is 128 bytes which is quite
> big for inotify extension indeed. The good news is that this amount of bytes
> seem to be required for the most descriptive fhandle
That 128-byte constan
On Wednesday 14 November 2012 14:56:00 Pavel Emelyanov wrote:
> >>> How much space does a typical file system need to encode a handle? Am I
> >>> right that for must it is just a few bytes? (I just glanced at the code
> >>> so I might be wrong.) In which case, could the handle buffer be
> >>> alloc
On Wed, Nov 14, 2012 at 02:56:00PM +0400, Pavel Emelyanov wrote:
> >>> How much space does a typical file system need to encode a handle? Am I
> >>> right that for must it is just a few bytes? (I just glanced at the code
> >>> so I might be wrong.) In which case, could the handle buffer be allocate
>>> How much space does a typical file system need to encode a handle? Am I
>>> right that for must it is just a few bytes? (I just glanced at the code
>>> so I might be wrong.) In which case, could the handle buffer be allocated
>>> dynamically depending on the underlying filesystem? Perhaps addin
On Wednesday 14 November 2012 14:46:42 Pavel Emelyanov wrote:
> On 11/14/2012 02:38 PM, Tvrtko Ursulin wrote:
> > On Wednesday 14 November 2012 14:13:41 Pavel Emelyanov wrote:
> >> On 11/14/2012 02:08 PM, Tvrtko Ursulin wrote:
> >>> On Wednesday 14 November 2012 13:58:12 Cyrill Gorcunov wrote:
> >>
On 11/14/2012 02:38 PM, Tvrtko Ursulin wrote:
> On Wednesday 14 November 2012 14:13:41 Pavel Emelyanov wrote:
>> On 11/14/2012 02:08 PM, Tvrtko Ursulin wrote:
>>> On Wednesday 14 November 2012 13:58:12 Cyrill Gorcunov wrote:
On Wed, Nov 14, 2012 at 09:50:55AM +, Tvrtko Ursulin wrote:
>
On Wednesday 14 November 2012 14:13:41 Pavel Emelyanov wrote:
> On 11/14/2012 02:08 PM, Tvrtko Ursulin wrote:
> > On Wednesday 14 November 2012 13:58:12 Cyrill Gorcunov wrote:
> >> On Wed, Nov 14, 2012 at 09:50:55AM +, Tvrtko Ursulin wrote:
> > You could not use a pointer and then allocate
On 11/14/2012 02:08 PM, Tvrtko Ursulin wrote:
> On Wednesday 14 November 2012 13:58:12 Cyrill Gorcunov wrote:
>> On Wed, Nov 14, 2012 at 09:50:55AM +, Tvrtko Ursulin wrote:
> You could not use a pointer and then allocate your buffers on the
> check
> point operation, freeing on rest
On Wed, Nov 14, 2012 at 02:10:50PM +0400, Pavel Emelyanov wrote:
> >>
> >> How can the c/r restore code reestablish the inode data if the dentry
> >> isn't there any more?
> >
> > By "deleted" I meant deleted from dcache, thus when we call for
> > open_by_handle_at with fhandle, the kernel reconst
On 11/14/2012 10:46 AM, Cyrill Gorcunov wrote:
> On Tue, Nov 13, 2012 at 02:38:08PM -0800, Andrew Morton wrote:
>> On Tue, 13 Nov 2012 12:00:32 +0400
>> Cyrill Gorcunov wrote:
>>
Dumb question: do we really need inotify_inode_mark.fhandle at all?
What prevents us from assembling this in
On Wednesday 14 November 2012 13:58:12 Cyrill Gorcunov wrote:
> On Wed, Nov 14, 2012 at 09:50:55AM +, Tvrtko Ursulin wrote:
> > > > You could not use a pointer and then allocate your buffers on the
> > > > check
> > > > point operation, freeing on restore?
> > >
> > > The problem is not alloca
On Wed, Nov 14, 2012 at 09:50:55AM +, Tvrtko Ursulin wrote:
> > > 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 t
On Wednesday 14 November 2012 13:38:49 Cyrill Gorcunov wrote:
> On Wed, Nov 14, 2012 at 09:20:51AM +, Tvrtko Ursulin wrote:
> > On Tuesday 13 November 2012 19:28:46 Cyrill Gorcunov wrote:
> > > On Tue, Nov 13, 2012 at 03:02:22PM +, Tvrtko Ursulin wrote:
> > > > Perhaps there could be a diff
On Wed, Nov 14, 2012 at 09:20:51AM +, Tvrtko Ursulin wrote:
> On Tuesday 13 November 2012 19:28:46 Cyrill Gorcunov wrote:
> > On Tue, Nov 13, 2012 at 03:02:22PM +, Tvrtko Ursulin wrote:
> > > Perhaps there could be a different way, where you could use additional
> > > space only when it is
On Tuesday 13 November 2012 19:28:46 Cyrill Gorcunov wrote:
> On Tue, Nov 13, 2012 at 03:02:22PM +, 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.
On Tue, Nov 13, 2012 at 02:38:08PM -0800, Andrew Morton wrote:
> On Tue, 13 Nov 2012 12:00:32 +0400
> Cyrill Gorcunov wrote:
>
> > > Dumb question: do we really need inotify_inode_mark.fhandle at all?
> > > What prevents us from assembling this info on demand when ->show_fdinfo()
> > > is
> > >
On Tue, 13 Nov 2012 12:00:32 +0400
Cyrill Gorcunov wrote:
> > Dumb question: do we really need inotify_inode_mark.fhandle at all?
> > What prevents us from assembling this info on demand when ->show_fdinfo() is
> > called?
>
> exportfs requires the dentry to be passed as an argument while inoti
On Tue, Nov 13, 2012 at 03:02:22PM +, Tvrtko Ursulin wrote:
> On Tuesday 13 November 2012 18:40:36 Cyrill Gorcunov wrote:
> > On Tue, Nov 13, 2012 at 12:37:23PM +, Tvrtko Ursulin wrote:
> > >> Which would give about 26K of additional memory if c/r get used here.
> > >>
> > >> Not a big nu
On Tuesday 13 November 2012 18:40:36 Cyrill Gorcunov wrote:
> On Tue, Nov 13, 2012 at 12:37:23PM +, Tvrtko Ursulin wrote:
> >> Which would give about 26K of additional memory if c/r get used here.
> >>
> >> Not a big number i guess?
> >
> > I am pretty sure there are desktop file indexing pa
On Tue, Nov 13, 2012 at 12:37:23PM +, Tvrtko Ursulin wrote:
>> Which would give about 26K of additional memory if c/r get used here.
>> Not a big number i guess?
>
> I am pretty sure there are desktop file indexing packages which use
> inotify or fanotify which will put a mark on every single
On Tue, Nov 13, 2012 at 12:19:25AM -0800, David Rientjes wrote:
> On Tue, 13 Nov 2012, Cyrill Gorcunov wrote:
>
> > > The question is, how many `struct inotify_inode_mark's are instantiated
> > > system-wide? Could be millions?
> >
> > Well, hard to tell, to be fair. On my testing machine only a
On Tue, 13 Nov 2012, Cyrill Gorcunov wrote:
> > The question is, how many `struct inotify_inode_mark's are instantiated
> > system-wide? Could be millions?
>
> Well, hard to tell, to be fair. On my testing machine only apache has been
> using inotify system as far as I remember, but for sure not
On Mon, Nov 12, 2012 at 11:40:01PM -0800, Andrew Morton wrote:
> On Tue, 13 Nov 2012 11:20:57 +0400 Cyrill Gorcunov
> wrote:
> > >
> > > Whoa. This adds 128+8 bytes to the inotify_inode_mark. That's a lot of
> > > bloat, and there can be a lot of inotify_inode_mark's in the system?
> >
> > Ye
On Tue, 13 Nov 2012 11:20:57 +0400 Cyrill Gorcunov wrote:
> > > struct inotify_inode_mark {
> > > struct fsnotify_mark fsn_mark;
> > > int wd;
> > > +#ifdef INOTIFY_USE_FHANDLE
> > > + __u8 fhandle[sizeof(struct file_handle) + MAX_HANDLE_SZ];
> > > +#endif
> > > };
> >
> > Whoa. This adds
On Mon, Nov 12, 2012 at 04:55:40PM -0800, Andrew Morton wrote:
> On Mon, 12 Nov 2012 14:14:43 +0400
> Cyrill Gorcunov wrote:
>
> > This file handle will be used in /proc/pid/fdinfo/fd
> > output, which in turn will allow to restore a watch
> > target after checkpoint (thus it's provided for
> > C
On Mon, 12 Nov 2012 14:14:43 +0400
Cyrill Gorcunov wrote:
> This file handle will be used in /proc/pid/fdinfo/fd
> output, which in turn will allow to restore a watch
> target after checkpoint (thus it's provided for
> CONFIG_CHECKPOINT_RESTORE only).
This changelog isn't very good.
What appear
This file handle will be used in /proc/pid/fdinfo/fd
output, which in turn will allow to restore a watch
target after checkpoint (thus it's provided for
CONFIG_CHECKPOINT_RESTORE only).
Signed-off-by: Cyrill Gorcunov
CC: Pavel Emelyanov
CC: Al Viro
CC: Alexey Dobriyan
CC: Andrew Morton
CC: Ja
This file handle will be used in /proc/pid/fdinfo/fd
output, which in turn will allow to restore a watch
target after checkpoint.
Signed-off-by: Cyrill Gorcunov
CC: Pavel Emelyanov
CC: Al Viro
CC: Alexey Dobriyan
CC: Andrew Morton
CC: James Bottomley
CC: "Aneesh Kumar K.V"
CC: Alexey Dobriy
31 matches
Mail list logo
