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

[ronnie sahlberg]

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 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.
>
> 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
>
--
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