On Wed, 2014-10-15 at 16:49 +0200, Jerome Martin wrote: > > On 10/15/2014 04:17 PM, Jerome Martin wrote: > > Hi Andrew, > > > > On 10/15/2014 03:51 PM, Andrew Watt wrote: > > [..] > >> IOError: [Errno 30] Read-only file system > > > > Out of the top of my head, I can't tell if this is the targetcli stack > > trying to perform some IO there (I can't imagine why) or if this is the > > reason why we did not include cdroms to allwoed TYPE_DISK devices for > > iblock. > > OK, I took a look at that and it is the iblock code that fails when > trying to enable the device. So it is obviously not supported in the > current state of affairs. Sorry about that :-( > > Nic, is having a RW device a hard requirement for iblock or is this > something that could/should be supported? So while the notion of using IBLOCK for a physical TYPE_ROM device might make sense, it's a particularly bad idea and we should continue to filter it from happening in userspace code. The reasoning is that IBLOCK itself only understands struct bio level I/O, which for the sake of this discussion means only READ + WRITE operations. In order to utilize physical TYPE_ROM devices, there are a number of SCSI MMC (multi-media command set) opcodes required to interface with the device, that struct bio and the raw block layer has no idea about. That said, folks should be using PSCSI passthrough for TYPE_ROM export, so that those MMC opcodes are dispatched directly to the device and not emulated by target code. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
