[stgt] [PATCH 1/1] Readonly disk LUNs

[Craig Johnston]

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 at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html