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
