Comments on: ZFS Borked

By: Scott

Scott — Fri, 25 Sep 2009 17:04:24 +0000

I have posted an update to this saga that was unexptected. The zfs data and the drives associated with the apparently b0rked zfs volume were not the problem. There was something screwed with the operating system.

By: Scott

Scott — Thu, 18 Jun 2009 15:40:51 +0000

koitsu, thanks for the comment. This has fallen off the top of my priority list for a bit, but when I get back to it I will post some comments here and maybe email you for some help, if the offer still stands. Then, if I learn something useful, I’l post it here for others to see too.

By: koitsu

koitsu — Thu, 18 Jun 2009 03:59:24 +0000

Comment in passing: format for Solaris will not be able to repair bad blocks on ATA or SATA disks. ATA/SATA do not have a “grown defect list” that is user (software) managable; there is no ATA command which says “internally mark LBA [x] bad”.

SCSI, on the other hand, has this capability. You might have seen it under the “defect” menu, when showing “grown” defects.

The bottom line with ATA/SATA disks and bad blocks is: replace the disk immediately. There’s a large number of internal “spare” blocks which the drive can silently remap data to (assuming the internal re-read or re-write was successful) which the kernel/userland has no knowledge of (though you might see a READ/WRITE timeout when this happens). Once all those spare blocks are used up, the drive will begin spitting back to the controller (thus the kernel) what LBA had a read/write failure.

The best way to determine the state of ATA/SATA disks is to use smartmontools, specifically smartctl -a, e.g. smartctl -a /dev/rdsk/c0t0d0s0. The SMART statistics shown will probably confuse you, but if you can provide some of them here, I’ll help decipher them + teach you how to read them.

By: Joe

Joe — Mon, 04 May 2009 05:45:38 +0000

Curious myself. I have two thumpers I havent had an issue with yet..

By: Ivan

Ivan — Fri, 01 May 2009 10:14:43 +0000

Scott, any luck?

By: Scott

Scott — Wed, 29 Apr 2009 15:02:54 +0000

Thanks for the suggestion. I know exactly which ones of the disks are bad, thanks to the hd utility for the x4500. I’ll give that a try.

By: Ivan

Ivan — Wed, 29 Apr 2009 10:28:29 +0000

Can you locate and physically pull the bad disks, vs. disabling the controller they’re attached to, then see if the Thumper will boot on it’s own again?

Normally, you should be able to do a zpool offline or zpool detach of the bad disks, but that would assume you could boot properly into ZFS – hense resorting to physically pulling the disks…