On 19 feb 2010, at 23.20, Ross Walker wrote: > 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.
But wouldn't the most disk like behavior then be to implement all the FUA, DPO, cache mode page, flush cache, etc, etc, have COMSTAR implement a cache just like disks do, maybe have a user knob to set the cache size (typically 32 MB or so on modern disks, could probably be used here too as a default), and still use /dev/rdsk devices? That could seem, in my naive limited little mind and humble opinion, as a pretty good approximation of how real disks work, and no OS should have to be more surprised than usual of how a SCSI disk works. Maybe COMSTAR already does this, or parts of it? Or am I wrong? /ragge _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
