On Fri, 2010-07-09 at 00:23 +0200, Ragnar Sundblad wrote:
> On 8 jul 2010, at 17.23, Garrett D'Amore wrote:
>
> > You want the write cache enabled, for sure, with ZFS. ZFS will do the
> > right thing about ensuring write cache is flushed when needed.
>
> That is not for sure at all, it all depends on what "the right thing"
> is, which depends on the application and/or what other measures
> there are for redundancy.
>
> Many raid controllers will respond to a flush [to persistant storage]
> by doing nothing, since the data already is in its write cache buffer
> which (hopefully) is battery backed or something.
> They will typically NOT flush the data to the drives and issue
> flush commands to the disks, and wait for that to finish, before
> responding.
I consider such behavior "bad", at least if not explicitly enabled, and
probably a bug.
>
> This means, that if your raid controller dies on you, some of your most
> recently written data will be gone. It may very well be vital metadata,
> and in the zfs world it may be data or metadata from several of the
> latest txgs, that is gone. Potentially, it could leave your file system
> corrupt, or arbitrary pieces of your data could be lost.
Yes, failure to flush data when the OS requests it is *evil*. Enabling
a write a cache should only be done if you believe your hardware is not
buggy in this respect. I guess I was thinking more along the lines of
simple JBOD controllers when I answered the question the first time -- I
failed to take into accounted RAID controller behavior.
- Garrett
>
> Maybe that is acceptable in the application, or maybe this is compensated
> for with other means as multiple raid controllers with the data mirrored
> over all of them which could reduce the risks by a lot, but you have to
> evaluate each separate case by itself.
>
> /ragge
>
> > For the case of a single JBOD, I don't find it surprising that UFS beats
> > ZFS. ZFS is designed for more complex configurations, and provides much
> > better data integrity guarantees than UFS (so critical data is written
> > to the disk more than once, and in areas of the drive that are not
> > adjacent to improve the chances of recovery in the event of a localized
> > media failure). That said, you could easily accelerate the write
> > performance of ZFS on that single JBOD by adding a small SSD log device.
> > (4GB would be enough. :-)
> >
> > - Garrett
> >
> > On Thu, 2010-07-08 at 15:10 +0200, Philippe Schwarz wrote:
> >> Hi,
> >>
> >> With dual-Xeon, 4GB of Ram (will be 8GB in a couple of weeks), two PCI-X
> >> 3Ware cards 7 Sata disks (750G & 1T) over FreeBSD 8.0 (But i think it's
> >> OS independant), i made some tests.
> >>
> >> The disks are exported as JBOD, but i tried enabling/disabling write-cache
> >> .
> >>
> >> I tried with UFS and ZFS on the same disk and the difference is
> >> overwhelming.
> >>
> >> With a 1GB file (greater than the ZFS cache ?):
> >>
> >> With Writecache disabled
> >> UFS
> >> time cp /mnt/ufs/rnd /mnt/ufs/rnd2
> >> real 2m58.073s
> >> ZFS
> >> time cp /zfs/rnd /zfs/rnd2
> >> real 4m33.726s
> >>
> >> On the same card with WCache enabled
> >> UFS
> >> time cp /mnt/ufs/rnd /mnt/ufs/rnd2
> >> real 0m31.406s
> >> ZFS
> >> time cp /zfs/rnd /zfs/rnd2
> >> real 1m0.199s
> >>
> >> So, despite the fact that ZFS can be twice slower than UFS, it is clear
> >> that Write-Cache have to be enabled on the controller.
> >>
> >> Any drawback (except that without BBU, i've got a pb in case of power
> >> loss) in enabling the WC with ZFS ?
> >>
> >>
> >> Thanks.
> >> Best regards.
> >>
> >>
> >
> >
> > _______________________________________________
> > zfs-discuss mailing list
> > zfs-discuss@opensolaris.org
> > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
>
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
