All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Christoph Hellwig <hch@lst.de>
Cc: trond.myklebust@primarydata.com, linux-nfs@vger.kernel.org
Subject: Re: pNFS SCSI layout support
Date: Tue, 1 Mar 2016 14:24:08 -0500	[thread overview]
Message-ID: <20160301192408.GC23792@fieldses.org> (raw)
In-Reply-To: <1456752247-6549-1-git-send-email-hch@lst.de>

On Mon, Feb 29, 2016 at 02:24:04PM +0100, Christoph Hellwig wrote:
> This series adds support the pNFS SCSI layout to both the NFS server
> and client.  It's a fairly simple extension to the existing block
> layout drivers, which relies on the Persistent Reservation API in
> the block layer merged a while ago.

Thanks, Christoph!

> On the server side we will now always export SCSI devices a SCSI
> layout.

If I understand correctly, you still require NFSEXP_PNFS (the "pnfs"
export option).  So, setting exporting with the "pnfs" option means
clients will see only one of block or SCSI layout support (or neither)
depending on what's possible, with preference for the SCSI layout.

> I though about allowing exports of multiple layour types
> for the same file system, but both the not really production ready
> nature of block layout fencing, and the horrors of passing options
> to NFS exports made me go with the simple way for now.

I agree that we should keep things simple, and agree that we should not
worry too much about block layout support.

I still wonder whether this is the best behavior.  How about also adding
the ability to configure out the block layout?  I think we'd want to be
sure it's completely off in production.

Also todo?:
	- wireshark support
	- testing, including of fencing and reboot recovery.  (And:
	  currently I just share a file between two vm's to use as my
	  shared block device, I guess I'll need to set up a real SCSI
	  target instead.)

I think there's not any additional documentation required--this is just
like block layout but without the need to configure fencing.  (Or do
people need to do some additional configuration of the SCSI devices?  Or
check the specs on their hardware to make sure it has support for the
right features?)

--b.

  parent reply	other threads:[~2016-03-01 19:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-29 13:24 pNFS SCSI layout support Christoph Hellwig
2016-02-29 13:24 ` [PATCH 1/3] nfs4.h: add SCSI layout defintions Christoph Hellwig
2016-02-29 13:24 ` [PATCH 2/3] nfs/blocklayout: add SCSI layout support Christoph Hellwig
2016-02-29 23:40   ` kbuild test robot
2016-03-01  8:11   ` kbuild test robot
2016-02-29 13:24 ` [PATCH 3/3] nfsd: " Christoph Hellwig
2016-03-01 19:24 ` J. Bruce Fields [this message]
2016-03-01 20:30   ` pNFS " Christoph Hellwig
2016-03-01 20:49     ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160301192408.GC23792@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=hch@lst.de \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@primarydata.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.