On Tue, 2019-04-02 at 21:51 +0000, Trond Myklebust wrote: > On Tue, 2019-04-02 at 15:41 -0400, J. Bruce Fields wrote: > > On Tue, Apr 02, 2019 at 01:26:19PM -0400, Bradley C. Kuszmaul > > wrote: > > > My simple model of metadata operations is to untar something like > > > the linux sources. > > > > > > Each file incurs a LOOKUP, CREATE, SETATTR, and WRITE, each of > > > which > > > is fairly high latency (even the WRITE ends up being done > > > essentially synchronously because tar closes the file after its > > > write(2) call.) > > > > An ordinary file write delegation can help with some of that. > > > > > I guess directory delegations might save the cost of LOOKUP. > > > > > > Is there any hope for getting write delegations? > > > > > > What other steps might be possible? > > > > Trond, wasn't there a draft describing your idea that a server > > should > > be > > able to grant a write delegation on create and delay the sync? I > > can't > > find it right now. > > Do you mean this one? > https://tools.ietf.org/html/draft-haynes-nfsv4-delstid-00 > BTW: assuming that we do get the above draft through the IETF, then we should look into delaying that SETATTR as well. Recall that the SETATTR exists because the server pushes the exclusive create verifier into the file timestamps. With the attribute delegations proposed in the above draft, then we can essentially defer that SETATTR to when we return the delegation, which means you would end up with 3 operations per file to untar: OPEN, WRITE, DELEGRETURN (with embedded SETATTR op). Only the first operation would need to be synchronous... Cheers Trond -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
