On Wed, 2005-05-11 at 00:00 +0200, Guennadi Liakhovetski wrote: > A follow up question - I recently used nbd to access a CD-ROM. It worked > nice, but, I had to read in 7 CDs, so, each time I had to replace a CD, I > had to stop the client, the server, then replace the CD, re-start the > server, re-start the client... I thought about extending NBD to (better) > support removable media, but then you start thinking about all those > features that your local block device has that don't get exported over > NBD... That's correct; NBD is basically just a remote data pipe type block device. It doesn't understand arbitrary packet commands. > Now, my understanding (sorry, without looking at any docs - yet) is, that > iSCSI is (or at least should be) free from these limitations. So, does it > make any sense at all extending NBD or just switch to iSCSI? Should NBD be > just kept simple as it is or would it be completely superseeded by iSCSI, > or is there still something that NBD does that iSCSI wouldn't (easily) do? Caveat: I've done quite a bit of work on nbd, so I'm biased. However, for what it does, nbd is extremely small, simple and efficient, so I think we'd want a hole in our head to replace it with something as complex and bloated as iSCSI---remember we'd need both a target and an initiator to do what nbd does today. However, there is room for improvement in nbd, notably the handling of packet commands, which looks to be eminently doable in the current infrastructure (this would basically make nbd a replicator for the linux block system, and would probably necessitate some client side changes to achieve). If you have any thoughts in this direction, you could drop an email to the maintainer. James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
