On Tue, Mar 01, 2016 at 09:30:12PM +0100, Christoph Hellwig wrote: > On Tue, Mar 01, 2016 at 02:24:08PM -0500, J. Bruce Fields wrote: > > 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. > > Being able to configure block layout eventually might be useful. Do > you simply want separate compile time options? It's not like a whole > lot of code will go away, it's mostly just entry points. Yeah, I wasn't thinking about the size of the code so much as supportability. > > Also todo?: > > - wireshark support > > I've mostly stayed clear of wiresharė. No problem, just noting it so I don't forget. > > - testing, including of fencing and reboot recovery. > > I've done a fair amount of testing, and the interesting part is > indeed fencing. The normal path is not very different from the block > layout driver. > > > (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.) > > The in-kernel lio target will work just fine. You can actually export > that directly to VMs using the vhost_scsi driver, but I've not tried > that option myself yet. > > > I think there's not any additional documentation required--this is just > > like block layout but without the need to configure fencing. > > Exactly. > > > (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?) > > Yes, the device needs to support persistent reservations. > > I can write up a little blurb on that. OK, thanks. --b. -- 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
