Re: GFS2: Add atomic_open support

[Steven Whitehouse]

Hi,

On Thu, 2013-06-06 at 18:53 +0100, Al Viro wrote:
> On Thu, Jun 06, 2013 at 03:50:12PM +0100, Steven Whitehouse wrote:
> > 
> > The following patch implements atomic_open for GFS2. This is mostly
> > straightforward, however there is one corner case which I've had to
> > deal with, beyond what would normally be expected for a local
> > filesystem.
> 
> Broken - what will happen if you hit a symlink, for starters?  On everything
> handled locally you should just return finish_no_open(file, dentry) and
> let the caller deal with that; the only cases that might make sense to
> handle in ->atomic_open() are regular files and directories.  For gfs2 it
> should be just regular files.  While we are at it, do you even need
> ->private_data for gfs2 directories?

I'm brewing up another version of the patch at the moment, which I will
post shortly. I don't understand why GFS2 specifically would not want to
do this with both files and directories? Why would it be different to
other filesystems in that respect?

We do need private data for gfs2 directories because that is required
for flock which should work equally well on directories as on regular
files. Potentially we might allocate it later, on the first call to
flock for example, but it has been done at open time so that we don't
have to test for it on every flock call. Also I was hoping to put some
info in there to assist with directory readahead at some stage too,

Steve.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/