On 09/10/2015 11:18 AM, Andy Grover wrote:
On 09/10/2015 03:53 AM, joeue Deng wrote:
Using 'targetcli /backstores/block/ create name dev [readonly=true]' to
set block with "ro write-thru" stat.
however, the initiator can still write to the iscsi device.
and I also find something similar,
https://bugzilla.redhat.com/show_bug.cgi?id=1036052
Is this not supported current?
the version i am using is :
targetcli-2.1.fb37-3.el7.src.rpm
python-configshell-1.1.fb14-1.el7.src.rpm
python-rtslib-2.1.fb50-1.el7.src.rpm
targetcli-fb-devel mailing list
[CCing target-devel for their thoughts]
This is because iblock's readonly parameter just results in the block
device being opened without FMODE_WRITE flag set. If the underlying
block device is actually read-only then iblock will pass them down and
they will fail in blkdev_write_iter(), like they should.
But if the iblock device is set read-only but the underlying device is
not then we get this situation, because opening without FMODE_WRITE does
nothing to prevent write bios from being performed.
I see two solutions:
1) Change iblock to fail write/write_same/discard requests to devices it
has as read-only, before they get to the backing block device
2) Change targetcli/rtslib so read-only is not settable by the user, but
instead is based on the state of the backing device (by checking
/sys/block/<x>/ro).
I lean towards #2. I tried #1 and it works, but the original goal (see
44bfd0185) wasn't to add a read-only feature to lio exports, it was to
get read-only block devices working.
And of course we also have write protect on the target side.. Maybe what
we do is #2, and then userspace can also set write protect on tpg luns
if backed by a read-only block device.
-- Andy
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
