I agree that device drivers should perform the bulk of the fault monitoring,
however I disagree that this absolves ZFS of any responsibility for checking
for errors. The primary goal of ZFS is to be a filesystem and maintain data
integrity, and that entails both reading and writing data to the devices. It
is no good having checksumming when reading data if you are loosing huge
amounts of data when a disk fails.
I'm not saying that ZFS should be monitoring disks and drivers to ensure they
are working, just that if ZFS attempts to write data and doesn't get the
response it's expecting, an error should be logged against the device
regardless of what the driver says. If ZFS is really about end-to-end data
integrity, then you do need to consider the possibility of a faulty driver.
Now I don't know what the root cause of this error is, but I suspect it will be
either a bad response from the SATA driver, or something within ZFS that is not
working correctly. Either way however I believe ZFS should have caught this.
It's similar to the iSCSI problem I posted a few months back where the ZFS pool
hangs for 3 minutes when a device is disconnected. There's absolutely no need
for the entire pool to hang when the other half of the mirror is working fine.
ZFS is often compared to hardware raid controllers, but so far it's ability to
handle problems is falling short.
Ross
> Date: Wed, 30 Jul 2008 09:48:34 -0500> From: [EMAIL PROTECTED]> To: [EMAIL
> PROTECTED]> CC: zfs-discuss@opensolaris.org> Subject: Re: [zfs-discuss]
> Supermicro AOC-SAT2-MV8 hang when drive removed> > On Wed, 30 Jul 2008, Ross
> wrote:> >> > Imagine you had a raid-z array and pulled a drive as I'm doing
> here. > > Because ZFS isn't aware of the removal it keeps writing to that > >
> drive as if it's valid. That means ZFS still believes the array is > > online
> when in fact it should be degrated. If any other drive now > > fails, ZFS
> will consider the status degrated instead of faulted, and > > will continue
> writing data. The problem is, ZFS is writing some of > > that data to a drive
> which doesn't exist, meaning all that data will > > be lost on reboot.> >
> While I do believe that device drivers. or the fault system, should > notify
> ZFS when a device fails (and ZFS should appropriately react), I > don't think
> that ZFS should be responsible for fault monitoring. ZFS > is in a rather
> poor position for device fault monitoring, and if it > attempts to do so then
> it will be slow and may misbehave in other > ways. The software which
> communicates with the device (i.e. the > device driver) is in the best
> position to monitor the device.> > The primary goal of ZFS is to be able to
> correctly read data which was > successfully committed to disk. There are
> programming interfaces > (e.g. fsync(), msync()) which may be used to ensure
> that data is > committed to disk, and which should return an error if there
> is a > problem. If you were performing your tests over an NFS mount then the
> > results should be considerably different since NFS requests that its > data
> be committed to disk.> > Bob> ======================================> Bob
> Friesenhahn> [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/>
> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/>
_________________________________________________________________
Find the best and worst places on the planet
http://clk.atdmt.com/UKM/go/101719807/direct/01/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
