On Thu, 1 Apr 2010 18:23:37 +1100 ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > I think it would be nice from a user viewpoint to use tgtimg to create > the device files for all type of devices, > including SBC DISK and MMC CDR blank disks. Yeah. That's why the tool was named tgtimg, not something like sscimg. > This would I think making a higher level mgmt tool easier since it > could then use the same command, but different flags, to create the > device image file for any kind of device. > This would also make the tgtimg manpage a natural place to describe > how to create the various types of disk image files, instead of > describing using dd to create a DISK in a readme or using touch to > create an empty file for CDR. > This would also provide a first step towards creating a unified > handling of device image metadata such as barcode, unit serial number. > Tgtimg could then become the tool to use to both create all device > image files and also to view/modify the device metadata of it. > > > Some smaller changes would be required though. > TAPE devices now store all its metadata in the file head. > This would not work for ISO images or DISK images since they are a raw > byte by byte copy of the device they represent and there is no space > for such a header in the file itself, without making them no longer a > byte by byte copy. I think DISK and ISO images being a byte by byte > copy is very valuable since these are standard formats to represent > these types of devices and I dont think it would be worth breaking > interoperability with other tools (or just dd a tgtd disk image onto a > real disk). > > > So, my suggestion would is > 1, enhance tgtimg to allow it to create DISK and CDR images too. > 2, use XATTR to store things like barcode, so we can store a barcode > for the CDR disks we create too. > As a special case, write the barcode for TAPE devices to the file > header too, just like today. This guarantees backward compatibility > with older versions of tgtd. > 3,enhance tgtd to read the barcode from XATTR for all device types. > As a special case, if no XATTR barcode was found, tape devices would > instead read the barcode from the file header. Unfortunately, we can't use xattr for ssc because the maximum size of xattr on some file systems (4K; one block size) is too small. > second step > 4, Start storing things such as ID and SN also in XATTR. I think > these types of metadata should preferably be stored with the image > file itself and be closely associated with it. Yeah, might be. Seems that users are happy about storing the configurations in targets.conf though. The problem is that the xattr is too small (and we don't have the standard that defines the minim size that file systems must support). There are more configurations about a logical unit than ID and SN, the physical block size, logical block size, mode params, etc. Probably we result in dealing with xattr and targets.conf... I like to avoid that. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
