ronnie sahlberg schrieb: > On Fri, Sep 12, 2008 at 12:25 AM, Tomasz Chmielewski <mangoo at wpkg.org> wrote: >> I will if it's not fixed when I send a bigger patch. >> >> To not duplicate work, the changes I'm working on currently are: >> >> - allow setting write caching per lun, >> - allow setting scsi_id, scsi_sn, product_id etc. other parameters, per lun >> - useful if one uses multipathd, but not only >> >> Any users of these features out there? >> > > Excellent. I will use these features! > > I would also like to be able specify the LUN for each backingstore, > not just that they always start at 1 and increment one by one. Yeah, I was thinking about this too. It will be needed if we want to have a predictable lun numbering when: - more than one lun/backing-store is used - they have different parameters set However, this feature will be added later. > I would like to specify the device type to use for each backingstore. > It currently assumes everything is a disk device. What --params= is needed here? > later I would also like to be able to configure for individual LUNs > things like : > Only these initiators can see/access this particular LUN. Is it at all possible? To allow initiators access to specified LUNs only? In tgtd, iSCSI RFCs etc.? > These particular initiators can see/access this LUN but the LUN > is read-only for them. As above - is it possible? > When you design the algorithms for setting the serial numbers > automatically, leave some reserved space in the field for > snapshots. > If in the future STGT gets the ability to snapshot a lun or a set of > luns, the snapshots should have different serial numbers than the > original production lun. Snapshots? Sounds like job for LVM? I'm not sure if we should go that far. > Maybe leaving the last 2 digits/characters in the serial number as 00 > for all LUNs, later if snapshots are added they automatically get 01 > 02 03... -- Tomasz Chmielewski http://wpkg.org -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html |