On Tue, 9 Mar 2010 17:00:50 +1100 ronnie sahlberg <ronniesahlberg@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
