RE: [PATCH/RFC] Lustre VFS patch

[braam]

Hi Trond,

Thanks for your very helpful reply ... Here are a few comments. 

> Peter, I have a couple of objections here
> 
>         vfs_intent-flags_rename-vanilla-2.6.patch and
>         vfs-intent_exec-vanilla-2.6.patch breaks NFS (though 
> ironically
>         it fixes CIFS) due to that gratuitous change of semantics from
>         FMODE_READ/FMODE_WRITE to O_RDONLY/O_WRONLY/O_RDWR. 
> Exactly why
>         couldn't Lustre work with the native VFS semantics?

Our error (this patch was wrong) - you are right we should use FMODE_READ.

>         vfs_intent-flags_rename-vanilla-2.6.patch also reverts the
>         format from being a union of intents for various operations to
>         being a single structure. This goes against what was 
> agreed upon
>         on linux-fsdevel when this issue was discussed last summer (in
>         fact Linus was the one who requested the union approach). What
>         justification exists now for a change?

Justification: Linus asked me to.  He said, there is only intent data for
open really so please remove the union.  I don't particularly care.

>         The vfs-intent_lustre-vanilla-2.6.patch + the 
> "intent_release()"
>         code. What if you end up crossing a mountpoint? How 
> do you then
>         know to which superblock/filesystem the private field 
> belongs if
>         there are more than one user of this mechanism?

Well spotted.  This is only used during the last component of lookup, so we
don't much care about this as we travers intermediate path names.  Have I
missed something else here?

>         vfs-revalidate_counter-vanilla-2.6.patch: can't 
> "counter" be put
>         into the private part of your intent structure so 
> that the whole
>         test may be done within Lustre?

Clever, we will do that.

>         vfs-revalidate_special-vanilla-2.6.patch: see the use of the
>         flag FS_REVAL_DOT in order to enable the revalidation of the
>         current directory for those filesystems that need to do so.

Didn't know this flag was there, we will use FS_REVAL_DOT.

Oleg Drokin is reworking the patches for these issues.

Thanks, this simplifies things!

- Peter -

-
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/