On Fri, Aug 12, 2016 at 7:42 PM, Kamble, Nitin A <Nitin.Kamble@xxxxxxxxxxxx> wrote: > >> On Aug 12, 2016, at 7:17 AM, Ilya Dryomov <idryomov@xxxxxxxxx> wrote: >> >> On Fri, Aug 12, 2016 at 1:38 AM, Kamble, Nitin A >> <Nitin.Kamble@xxxxxxxxxxxx> wrote: >>> >>> SCSI block devices has SG_IO IOCTL interface by which applications can identify the device uniquely. This helps applications identify the device uniquely without relying on the device file names or any other mechanisms. >>> >>> For more details l ook at the manpage of sg_inq commnad. https://manned.org/sg_inq >>> >>> Some of the non SCSI devices also support this SG_IO interface for inquiry. Examples include SATA, NVME, Virtual Disks. >>> >>> It is desired to identify every RBD uniquely just from the device file. It will help in using RBD devices as drop in replacement for SCSI/SATA devices. Currently the RBD code in ceph-client does not support the SG_IO ioctl interface for inquiry to identify the device uniquely. Has adding the SG_IO ioctl interface to the RBD devices ever been considered before? >> >> No, SG_IO hasn't come up before, and we don't really have a good >> established way of doing that at all - if we had one, wiring up SG_IO >> (assuming no objections from SCSI maintainers) wouldn't be a problem. >> One approach is to concatenate a cluster-wide UUID with pool, image and >> snapshot IDs, but the problem there is that images can be moved between >> pools and clusters and v1 images don't have an image ID. > > I am surprised to know that images can be moved across pools and clusters. The feature request for moving images across pools was rejected here: http://tracker.ceph.com/issues/2305 . Also the rbd man page says rbd rename across pools is not supported. (http://docs.ceph.com/docs/master/man/8/rbd/) > > Is it a currently available feature? There are a couple of hacky, undocumented and unsupported ways which I won't describe. The above was just a very bad way of saying that current v2 image IDs are guaranteed to be unique only within a pool and can be the duplicated between different pools on the same cluster and different clusters. > >> >> Mike recently ran into the need to uniquely identify RBD devices for >> his multipath-tools work and I think he ended up using some variant of >> the above approach, grabbing IDs from /sys/bus/rbd. (The cluster_uuid >> and snap_id attributes currently don't exist, but will be added in the >> next kernel release.) >> >> It would make this a lot easier if we started generating a unique UUID >> for the image and each snapshot at image/snapshot creation time. Jason? >> > > Image UUID seems like the right direction. With UUIDs we would be in much better shape - current v2 image ID is relatively very short. We can couple it with a cluster UUID too. > If that UUID needs to be really unique, then image copy also need to create a new UUID. It would be akin to the UUID of a partition. I suppose including a tune2fs -U functionality wouldn't hurt. I'll add that to the ticket. Thanks, Ilya -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
