On Fri, Nov 28, 2014 at 03:45:24PM +0000, Patrick Farrell wrote: > Dan, > > I disagree about the change suggested here. In this particular code, > 'object_attr' is distinct from 'attr', as in a 'setattr' call on an > inode. 'cl_object' is a distinct thing from an inode/file on disk, > and specifying it is the objects attr is helpful in understanding > there is not a direct relationship to 'attr' in the general filesystem > sense. (cl_object attrs are used in determining actual on disk > attributes, but there is not a one-to-one correspondence.) > > I am willing to be corrected, but that is my first feeling here.
I haven't looked at it deeply. Loïc was suggesting that we need new locking functions to deal with lustre's unwieldy naming schemes and I think we should just fix the names... We already have a cl_attr struct. Is that different from what we're locking here? I don't think anyone will think this takes an inode argument. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
