[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <232829.1582128970@warthog.procyon.org.uk>
Date: Wed, 19 Feb 2020 16:16:10 +0000
From: David Howells <dhowells@...hat.com>
To: Christian Brauner <christian.brauner@...ntu.com>
Cc: dhowells@...hat.com, viro@...iv.linux.org.uk, raven@...maw.net,
mszeredi@...hat.com, christian@...uner.io,
linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/19] VFS: Filesystem information and notifications [ver #16]
Christian Brauner <christian.brauner@...ntu.com> wrote:
> I mainly have an organizational question. :) This is a huge patchset
> with lots and lots of (good) features. Wouldn't it make sense to make
> the fsinfo() syscall a completely separate patchset from the
> watch_mount() and watch_sb() syscalls? It seems that they don't need to
> depend on each other at all. This would make reviewing this so much
> nicer and likely would mean that fsinfo() could proceed a little faster.
I can split it up again, but it's not quite as independent as it seems.
There's a notification counter added to both the mount struct and the
super_block struct. This is bumped by notifications and retrieved by
fsinfo(). You need this in the event that there's an overrun and you have to
rescan the whole tree.
So to actually make use of the mount/sb notification facilities, you need
fsinfo() as well.
David
Powered by blists - more mailing lists