On 11/28/06, Elizabeth Schwartz <[EMAIL PROTECTED]> wrote:
On 11/28/06, David Dyer-Bennet <[EMAIL PROTECTED]> wrote:
> Looks to me like another example of ZFS noticing and reporting an
> error that would go quietly by on any other filesystem. And if you're
> concerned with the integrity of the data, why not use some ZFS
> redundancy? (I'm guessing you're applying the redundancy further
> downstream; but, as this situation demonstrates, separating it too far
> from the checksum verification makes it less useful.)
Well, this error meant that two files on the file system were inaccessible,
and one user was completely unable to use IMAP, so I don't know about
unnoticeable.
Is that only because ZFS knows the file is corrupt, and refuses to
allow access? Possibly another filesystem would happily serve
whatever bits happened to come back from the RaidKing, not knowing any
better.
How would I use more redundancy?
Create a RAIDZ or mirror vdev and put that in the pool, instead of
putting a single device in the pool. You're probably counting on your
RaidKing to handle the RAID, and then running ZFS on top of that, but
this looks like a situation where the RaidKing had some kind of
unrecoverable (and possibly undetected) error. Either it did, or else
ZFS corrupted the data all by itself. One or the other, anyway, has
let you down seriously. (I'm inclined to have considerable faith in
ZFS at this point, and am not familiar with RaidKing; what's needed is
some kind of actual evidence of which side failed, not guesses.)
Stacking them that way, running the redundancy in a separate layer
from ZFS, means you're not getting the full benefit from the
integration of filesystem, volume management, and redundancy handling
all into ZFS. On the other hand, running on old hardware that's
heavily set up for offloading RAID activities from the CPU, that might
be the best available tradeoff; I'm not very familiar with such
hardware.
--
David Dyer-Bennet, <mailto:[EMAIL PROTECTED]>, <http://www.dd-b.net/dd-b/>
RKBA: <http://www.dd-b.net/carry/>
Pics: <http://www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss