On 19 feb 2010, at 23.22, Phil Harman wrote: > On 19/02/2010 21:57, Ragnar Sundblad 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? >> >> /ragge >> > > Yes, that would be nice wouldn't it? But the world is seldom that simple, is > it? For example, Sun's first implementation of zvol was unsafe by default, > with no cache flush option either. > > A few years back we used to note that one of the reasons Solaris was slower > than Linux at fileystems microbenchmarks was because Linux ran with the write > caches on (whereas we would never be that foolhardy).
(Exactly, and there are more "better fast than safe" evilness in that OS too, especially in the file system area. That is why I never use it for anything that should store anything.) > And then this seems to claim that NTFS may not be that smart either ... > > http://blogs.sun.com/roch/entry/iscsi_unleashed > > (see the WCE Settings paragraph) > > I'm only going on what I've read. But - all normal disks come with write caching enabled, so in both the Linux case and the NTFS case, this is how they always operate, with all disks, so why should an iSCSI lun behave any different? If they can't handle the write cache (handle syncing, barriers, ordering an all that), they should turn the cache off, just as Solaris does in almost all cases except when you use an entire disk for zfs (I believe because solaris UFS was never really adapted to write caches). And they should do that for all SCSI disks. (I seem to recall at in the bad old days you had to disable the write cache yourself if you should use a disk on SunOS, but that was probably because it wasn't standardized, and you did it with a jumper on the controller board.) So - I just do not understand why an iSCSI lun should not try to emulate how all other SCSI disks work as much as possible? This must be the most compatible mode of operation, or am I wrong? /ragge _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
