On Feb 19, 2010, at 4:57 PM, Ragnar Sundblad <ra...@csc.kth.se> wrote:
On 18 feb 2010, at 13.55, Phil Harman wrote:
...
Whilst the latest bug fixes put the world to rights again with
respect to correctness, it may be that some of our performance
workaround are still unsafe (i.e. if my iSCSI client assumes all
writes are synchronised to nonvolatile storage, I'd better be
pretty sure of the failure modes before I work around that).
But are there any clients that assume that an iSCSI volume is
synchronous?
Isn't an iSCSI target supposed to behave like any other SCSI disk
(pSCSI, SAS, FC, USB MSC, SSA, ATAPI, FW SBP...)?
With that I mean: A disk which understands SCSI commands with an
optional write cache that could be turned off, with cache sync
command, and all those things.
Put in another way, isn't is the OS/file systems responsibility to
use the SCSI disk responsibly regardless of the underlying
protocol?
That was my argument a while back.
If you use /dev/dsk then all writes should be asynchronous and WCE
should be on and the initiator should issue a 'sync' to make sure it's
in NV storage, if you use /dev/rdsk all writes should be synchronous
and WCE should be off. RCD should be off in all cases and the ARC
should cache all it can.
Making COMSTAR always start with /dev/rdsk and flip to /dev/dsk if the
initiator flags write cache is the wrong way to go about it. It's more
complicated then it needs to be and it leaves setting the storage
policy up to the system admin rather then the storage admin.
It would be better to put effort into supporting FUA and DPO options
in the target then dynamically changing a volume's cache policy from
the initiator side.
-Ross
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
