I stand corrected. Apparently there is no LOOKUP, so maybe read-only
directory delegations don't help at all with untar.
-Bradley
On 4/2/19 1:26 PM, 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.)
I guess directory delegations might save the cost of LOOKUP.
Is there any hope for getting write delegations?
What other steps might be possible?
-Bradley
On 4/2/19 12:11 PM, bfields@xxxxxxxxxxxx wrote:
On Mon, Apr 01, 2019 at 12:21:49PM -0400, Bradley C. Kuszmaul wrote:
Hi, I'm the architect for Oracle's File Storage Service. FSS is
basically a big scalable NFS server that runs in Oracle's cloud.
Our metadata operations have higher latency than a vanilla NFS
server (e.g., a Linux NFS server serving a XFS stored on a block
device), and we suspect that directory delegations would make a big
performance improvement.
I understand, however, that essentially no one implements directory
delegations.
Can anyone fill me in on the current thinking of the future of
support for directory delegations in the Linux NFS client?
Maybe somebody else will speak up, but I don't know of any effort to
implement directory delegations.
What metadata operations specifically are you worried about? The
directory delegations that are specified in RFC 5661 are read-only.
Which might explain some of the lack of interest.
But there may be other steps that we could take to improve matters.
--b.
