Thanks for your input. There was a few minor details that would require re-working in my patch. For example "leaking" devicespecific code out into the spc mode-sense6/10 commands that would have to be done slightly differently. I will generate a new patch and send for review in a few days. regards ronnie sahlberg On Sat, Apr 3, 2010 at 11:05 AM, Craig Johnston <agspoon@xxxxxxxxx> wrote: > You asked for real-life examples for why one would want a read-only > target. I work for a large company, and currently use 5 different > types of iSCSI SAN from different vendors. All of these support > read-only targets, and most support setting this attribute on a > per-initiator basis. > > We make extensive use of this capability to provide policy enforcement > at the SAN, rather than rely on the user (initiator) to "do the right > thing". And as someone pointed out, even if a host mounts an ext3 > target as "ro", it doesn't mean that there will be no writing to the > file system metadata. > > We serve read-only targets for general stores of data that we do not > want modified, and we rely on the SAN to provide that assurance. > > We also use a single read-only target as the root file system for > numerous network booted hosts. There are tricks used to personalize > each host at boot time, but the underlying file system is immutable > (ala a live CD). > > There is also a use case for having the read-only attribute apply on a > per-initiator basis. When it comes time to re-deploy new content or a > new file system to the target volume, we ensure that all read-only > initiators are disconnected, connect from a "read-write" enabled > initiator, make the updates, disconnect, and make the target available > again. No need to get onto the actual host SAN. In fact if you can't > get onto the actual SAN, this is the only way to support a read-only > target, otherwise you can never populate it. ;) > > The proposed patch to add a "read-only" attribute to a target > configuration for STGT would be VERY welcome to me and others who use > a SAN in the same way. > > Craig > -- > 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 > -- 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
