RE: [nfsv4] [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY

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

 



CB_RECALL_ANY was added based on Panasas experience with its own protocols.   When you have
100's (or 1000's) of clients and millions of files for which you maintain state, it is
very much worth optimizing how the server can reclaim this state.
	Brent

-----Original Message-----
From: nfsv4-bounces@xxxxxxxx [mailto:nfsv4-bounces@xxxxxxxx] On Behalf Of Jim Rees
Sent: Monday, October 31, 2011 11:32 AM
To: Trond Myklebust
Cc: linux-nfs@xxxxxxxxxxxxxxx; nfsv4 list
Subject: Re: [nfsv4] [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY

Trond Myklebust wrote:

  I don't necessarily disagree with what you are saying, but I have yet to
  see a single server side implementation of CB_RECALL_ANY, let alone any
  numbers that indicate performance or responsiveness problems resulting
  from our existing client-side implementation.
  
  I therefore find it hard to understand why optimising this particular
  code is such a high priority, or why a patch that is adding per-file
  layoutreturns to initiate_bulk_draining() is going to help anything at
  all.

Testing between the linux block layout client and the EMC block layout
server revealed a deadlock when the server had handed out some number of
layouts and couldn't hand out any more.  So now the EMC block layout server
implements CB_RECALL_ANY.  So yes, this solves a real world problem, and
yes, there is a server that implements this.

We had some discussions at the time, and I don't remember if those were on
the linux-nfs list or in some other forum.  We decided that the client was
in the best position to decide which layouts were no longer needed, so we
needed some way for the server to tell the client to return some layouts
without specifying which ones.  CB_RECALL_ANY seemed custom-made for this
purpose, so we used it.

I don't think it would be appropriate for the server to recall all layouts
when it only needs some of them back.
_______________________________________________
nfsv4 mailing list
nfsv4@xxxxxxxx
https://www.ietf.org/mailman/listinfo/nfsv4
--
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


[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