On Tue, Mar 31, 2009 at 11:00:50PM +0300, Benny Halevy wrote: > On Mar. 31, 2009, 22:42 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > On Tue, Mar 31, 2009 at 09:36:08PM +0300, Benny Halevy wrote: > >> On Mar. 31, 2009, 4:44 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > >>> On Mon, Mar 30, 2009 at 05:37:37PM +0300, Benny Halevy wrote: > >>>> Bruce, > >>>> > >>>> As I mentioned in a reply to Trond, > >>>> "nfsd41: support for 3-word long attribute bitmask" > >>>> changes the server fattr encoding logic so it may send > >>>> back a bitmap of length 1, even if the client sent a > >>>> bitmap of length 2, if the second word of the bitmap > >>>> is zero. Although I think this a valid implementation > >>>> and other servers may do the same, it seems sub-optimal > >>>> for the client's decoding of acl of fs_locations. > >>> "suboptimal" means it does some extra memcpy'ing? > >> Yes, I believe so. > >> > >>>> It's pretty easy to revert to the old behavior on the server > >>>> by always returning at least two bitmap words, or, if we > >>>> keep the bitmap length, not just the val, in nfsd4_decode_bitmap > >>>> we can return a bitmap of the same length in the reply. > >>> Odd thing to have to do, but OK. --b. > >> What would you prefer to do? > >> Revert to old behavior by returning at least two bitmap words > >> or use the args bitmap length for encoding the res? > > > > Whichever requires the least code? I don't know. > > The former seems simpler to code. > > > > > If the client really needs this, then it needs to be agreed on by more > > than just the linux server. It's unfortunate if making this arbitrary > > undocumented choice of result encoding makes a significant difference to > > the client's performance. > > I think that currently it affects only getacl and I have no measurements > of to what extent the effect of performance is. I'd rather just not worry about it. If it turns out to be a problem then we can try to figure out a less fragile solution. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
