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

[FUJITA Tomonori]

On Tue, 9 Mar 2010 17:00:50 +1100
ronnie sahlberg <ronniesahlberg at gmail.com> wrote:

> Ok, initially it was triggered by the other thread bout reaonly for
> some initiators.
> That is probably a very bad example since there are other issues with
> that approach and why it should not be recommended.

Yeah, that approach is one of the typical examples that you should
not do.


> There are three cases I can come up with that would make users want a
> readonly disk.
> 
> 1, share a disk across many initiators as readonly and avoid having
> the various initiators write and update atime when a file is accessed.
> this is a weak argument since one could just mount the fs with noatime

Yeah, and if file systems try to write to a read-only lu and get an
error, then the majority of file systems just stop working. So the
logic to setting a lu read-only behind a file system doesn't work.


> 2, snapshots. many filesystems support fs or file level snapshots.
> Many of them only support readonly access to the snapshot device/file.
> making the lun signal it is readonly back to the initiator reduces the
> amount of surpsrise to an initiator when it does a mode sense and the
> device says read-write ok but when it later tries a write to update a
> inode atime its getting a sense code back.
> 
> 3, maybe you just don trust some initiators and just dont want them to
> be able to write to the device ?

Well, then you need to configure 'read-only' attribute per initiator?
It doesn't look the patch supports it?

I want to wait until someone shows the greatly useful stories of this
feature. My NetApp box doesn't support such feature, so I guess that
we are fine without it, I guess.
--
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