On Sun, Feb 21, 2010 at 12:41, Ethan <notet...@gmail.com> wrote: > > Update: I'm stuck. Again. > > To answer "For curiosity's sake, what happens when you remove (rename) your > dir with the symlinks?": it finds the devices on p0 with no problem, with > the symlinks directory deleted. > > After clearing the errors and scrubbing again, no errors were encountered > in the second scrub. Then I offlined the disk which had errors in the first > scrub. > > I followed the suggestion to thoroughly test the disk (and remap any bad > sectors), filling it with random-looking data by encrypting /dev/zero. > Reading back and decrypting the drive, it all read back as zeros - all > good. > > I then checked the SMART status of the drive, which had 0 error rates for > everything. I ran the several-hour "extended self-test", whatever that does, > after which I had two write errors on one drive which weren't there before. > I believe it's the same drive that had the zfs errors, but I did the SMART > stuff in linux, not being able to find SMART tools in solaris, and I haven't > been able to figure out which drive is which. Is there a way to get a > drive's serial number in solaris? I could identify it by that. > > I scrubbed again with the pool degraded. No errors. > > NAME STATE READ WRITE CKSUM > q ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > c9t4d0p0 ONLINE 0 0 0 > c9t5d0p0 ONLINE 0 0 0 > c9t2d0p0 ONLINE 0 0 0 > 3763020893739678459 UNAVAIL 0 0 0 was > /dev/dsk/c9t1d0p0 > c9t0d0p0 ONLINE 0 0 0 > > errors: No known data errors > > I tried zpool replace on the drive. > # zpool replace q 3763020893739678459 c9t1d0 > cannot replace 3763020893739678459 with c9t1d0: device is too small > > Victor was right. I went into 'format' and fought with it for a while. > Moving the beginning of slice 0 from block 256 down to block 34 was simple > enough, but I can not figure out how to tell it I don't want 8MB in slice 8. > Is it even possible? I haven't got 8MB to spare (as silly as that sounds for > a 1.5TB drive) - if I can't get rid of slice 8, I may have to stick with > using p0's. I haven't encountered a problem using them so far (who needs > partition tables anyway?) but I figured I'd ask if anybody had ideas about > getting back that space. > What's the 8MB for, anyway? Some stuff seems to indicate that it has to do > with booting the drive, but this will never be a boot drive. That seems to > be for VTOC stuff, not EFI, though. I did look at switching to VTOC labels, > but it seems they don't support disks as large as I am using, so I think > that's out. > I also see "Information that was stored in the alternate cylinders area, > the last two cylinders of the disk, is now stored in slice 8." ( > http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWaadm/SYSADV1/p117.html) > Not sure what an "alternate cylinders area" is - it sounds sort of like > remapping bad sectors, but that's something that the disk does on its own. > > So, can I get the 8MB back? Should I use p0? Is there another option I'm > not thinking of? (I could always try diving into the EFI label with a hex > editor and set it the way I please with no silly slice 8) > > -Ethan > > I did a replace onto p0 of the drive I'd randomized, and did a scrub. No errors. (Then I did another scrub, just for the hell of it; no errors again.)
I feel fairly content staying with p0's, unless there's a good reason not to. There are a few things I'm not entirely certain about: - Is there any significant advantage to having a partition table? - If there is, is it possible to drop the 8MB slice 8 so that I can actually have enough space to put my raid on slice 0? - Should I replace the disk that had errors on the initial scrub, or is it probably sufficient to just be wary of it, scrub frequently, and replace it if it encounters any more errors? -Ethan
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
