[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ceph-devel
Subject:    Re: mds: handle xattrs on inode creation
From:       Sage Weil <sage () newdream ! net>
Date:       2011-10-21 21:31:24
Message-ID: Pine.LNX.4.64.1110211428371.20118 () cobra ! newdream ! net
[Download RAW message or body]

On Fri, 21 Oct 2011, Noah Watkins wrote:
> ----- Original Message -----
> > From: "Sage Weil" <sage@newdream.net>
> >
> > The mode for the newly created object is being passed to the mds for
> > each
> > request as part of the args struct/union. And it looks like it's being
> > used on the MDS for everything except symlink (which always gets 0777
> > +
> > the type bits). For example, for mkdir, it's
> > 
> > unsigned mode = req->head.args.mkdir.mode;
> > mode &= ~S_IFMT;
> > mode |= S_IFDIR;
> 
> Since S_IFDIR (for example) is added by the MDS and the ACL is
> computed before the initial MDS request is made (and the final
> mode is available), the ACL code ends up looking like:

I would characterize it as "the MDS ensures the file type bits of the mode 
are correct."  

> if (req->op == CEPH_MDS_OP_MKDIR) { ...
> 
>   rather than
> 
> if (S_ISDIR(mode)) { ...
> 
> which, I suppose isn't a big deal. Should we go with the this,
> or is there a potential to fully compute the mode arguments
> on the client to allow reuse of the nice S_ISDIR (etc...) macros?

Yeah, just compute the whole thing on the client.  

The MDS does fundamentally different things for different op types, and 
sometimes creation is implicit etc., so don't worry about that part.  :)
In the end, they all funnel into prepare_new_inode() with a correct mode, 
so that's where the "magic" of setting those initial xattrs happens.

sage

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]