Hello Robert,
Thursday, July 6, 2006, 1:49:34 AM, you wrote:
RM Hello Eric,
RM Monday, June 12, 2006, 11:21:24 PM, you wrote:
ES I reproduced this pretty easily on a lab machine. I've filed:
ES 6437568 ditto block repair is incorrectly propagated to root vdev
ES To track this issue. Keep
Hello Eric,
Friday, June 9, 2006, 5:16:29 PM, you wrote:
ES On Fri, Jun 09, 2006 at 06:16:53AM -0700, Robert Milkowski wrote:
bash-3.00# zpool status -v nfs-s5-p1
pool: nfs-s5-p1
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was
Hello Jeff,
Saturday, June 10, 2006, 2:32:49 AM, you wrote:
btw: I'm really suprised how SATA disks are unreliable. I put dozen
TBs of data on ZFS last time and just after few days I got few hundreds
checksum error (there raid-z was used). And these disks are 500GB in
3511 array. Well that
On Mon, Jun 12, 2006 at 10:49:49AM +0200, Robert Milkowski wrote:
Well, I just did 'fmdump -eV' and last entry is from May 31th and is
related to pools which are already destroyed.
I can see another 1 checksum error in that pool (I did zpool clear
last time) and it's NOT reported by
Richard Elling wrote:
Robert Milkowski wrote:
btw: I'm really suprised how SATA disks are unreliable. I put dozen
TBs of data on ZFS last time and just after few days I got few
hundreds checksum error (there raid-z was used). And these disks are
500GB in 3511 array. Well that would explain
btw: I'm really suprised how SATA disks are unreliable. I put dozen
TBs of data on ZFS last time and just after few days I got few hundreds
checksum error (there raid-z was used). And these disks are 500GB in
3511 array. Well that would explain some fsck's, etc. we saw before.
I suspect
Jeff Bonwick wrote:
btw: I'm really suprised how SATA disks are unreliable. I put dozen
TBs of data on ZFS last time and just after few days I got few hundreds
checksum error (there raid-z was used). And these disks are 500GB in
3511 array. Well that would explain some fsck's, etc. we saw
