[stgt] [PATCH 1/1] Readonly disk LUNs
ronniesahlberg at gmail.com
Sun Apr 4 00:50:54 CEST 2010
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
that would have to be done slightly differently.
I will generate a new patch and send for review in a few days.
On Sat, Apr 3, 2010 at 11:05 AM, Craig Johnston <agspoon at gmail.com> 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.
> 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
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
More information about the stgt