Hello eric, Wednesday, April 18, 2007, 10:53:59 PM, you wrote:
ek> On Apr 18, 2007, at 2:35 AM, Richard L. Hamilton wrote: >> Well, no; his quote did say "software or hardware". The theory is >> apparently >> that ZFS can do better at detecting (and with redundancy, >> correcting) errors >> if it's dealing with raw hardware, or as nearly so as possible. >> Most SANs >> _can_ hand out raw LUNs as well as RAID LUNs, the folks that run >> them are >> just not used to doing it. >> >> Another issue that may come up with SANs and/or hardware RAID: >> supposedly, storage systems with large non-volatile caches will >> tend to have >> poor performance with ZFS, because ZFS issues cache flush commands as >> part of committing every transaction group; this is worse if the >> filesystem >> is also being used for NFS service. Most such hardware can be >> configured to ignore cache flushing commands, which is safe as long as >> the cache is non-volatile. ek> The non-volatile cache issues are being covered by: ek> 6462690 sd driver should set SYNC_NV bit when issuing SYNCHRONIZE ek> CACHE to SBC-2 devices ek> PSARC 2007/053 ek> The PSARC case has been approved, and Grant is finishing up the code ek> changes. Has an analysis of most common storage system been done on how they treat SYNC_NV bit and if any additional tweaking is needed? Would such analysis be publicly available? -- Best regards, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
