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

ronnie sahlberg ronniesahlberg at gmail.com
Fri Mar 12 03:49:02 CET 2010

On Fri, Mar 12, 2010 at 12:57 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> 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?

No the patch is per target so to have some initiators have read-write
and others have read-only would require two separate targets.
One target read-only and one read-write.Both targets exporting the
same physical file as a lun.

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

That is fine.

Netapp however is mainly a nas box, where iscsi is primarily a
value-add for a cifs server so you can also host your exchange
database on this very expensive server. I dont think this is
comparable to requirements or usecases for dedicated san/iscsi boxens
and gateways like cisco96xx, symmetrix, lhn,  falcon, and similar.

Windows until very very recently could just not handle read-only
storage disks at all, no matter what since ntfs would become very
unhappy. So for something aimed primarily at ntfs and windows,
readonly would be pointless.

I dont think this feature is that vital. I think it is useful but not
vital. We can add it later if there is big demand for it.

If you dotn want to add it, that is fine.

ronnie sahlberg
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 mailing list