On Tue, 2019-04-02 at 20:28 -0400, bfields@xxxxxxxxxxxx wrote: > On Tue, Apr 02, 2019 at 09:51:42PM +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 > > Maybe it's too subtle for me. What's the part that allows delaying > sync > on create? > The create itself needs to be sync, but the attribute delegations mean that the client, not the server, is authoritative for the timestamps. So the client now owns the atime and mtime, and just sets them as part of the (asynchronous) delegreturn some time after you are done writing. Were you perhaps thinking about this earlier proposal? https://tools.ietf.org/html/draft-myklebust-nfsv4-unstable-file-creation-01 Cheers Trond -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
