Re: directory delegations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux