On Jan 23, 2008, at 8:01 AM, UNIX admin wrote: There's this great new utility available on Solaris 10 Update 2, and Nevada call "zpool". Seriously, run the following two commands, and once complete, you can then do whatever you want with the disk without seeing additional errors.
# zpool create delete_me c2t0d0 # zpool destroy delete_me You now have a disk that has all of the available space stored in Slice 0 of c2t0d0. Now you can run any disk utility of your choosing, repartition and layout the disk as you see fit. Assuming that you have run format, and repartition the disk into two different 250GB partitions (say slices 0 & 1), be VERY careful when running "zpool create ... " again, in assuring that you specify the slice number this time around, (I'll assume 0) of the partition you will be using for the ZFS storage pool. # zpool create <pool-name> c2t0d0s0 - Jim > Does anybody know when 6446146 will be fixed? > > (DISCLAIMER: rant follows) > > I can't believe that this has been in Solaris since Solaris 10 (and > earlier, as early as 1993), and is still lingering around. > > I have two USB disks I bought yesterday, and hooked up to my SPARC > workstation. 2 x 500GB. I wanted to use 250GB for a zpool, and > 250GB for Oracle ASM. > > And what happens? Well, I hit a bug which has made his rounds in > various forms since 1993, but was never properly corrected, and > today is 2008. > > So I go and apply the latest recommended patch cluster; reboot; and > I still can't properly either partition the disk with fdisk(1M), or > format(1M) it. I get: > > [EMAIL PROTECTED]/]> fdisk /dev/rdsk/c2t0d0s2 > fdisk: Cannot open device /dev/rdsk/c2t0d0s2. > > OK, so fdisk(1M) is giving me the finger, but I've got a trick or > two left to play: > > [EMAIL PROTECTED]/]> prtvtoc /dev/rdsk/c4t0d0s2 | fmthard -s '-' /dev/ > rdsk/c2t0d0s2 > fmthard: Partition 0 overlaps partition 2. Overlap is allowed > only on partition on the full disk partition). > > I know that fmthard(1M) is lying or busted, because apparently, ZFS > has no problem: > > [EMAIL PROTECTED]/]> zpool status > pool: space > state: ONLINE > scrub: scrub in progress, 15.56% done, 1h2m to go > config: > > NAME STATE READ WRITE CKSUM > space ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c2t0d0s0 ONLINE 0 0 0 > c4t0d0s0 ONLINE 0 0 0 > > errors: No known data errors > > So, I've hit a bug. This gets me on a hunt, and I find a whole > string of related bugs which are plaguing both fdisk(1M), > format(1M), and sometimes fmthard(1M). At the heart of the problem > seems to be the fact that fdisk(1M) uses disk geometry when doing > slice and write calculations, except that when it's time to write > the disk label, the label gets mangled. These "mangles" have been > fixed in various forms and fixes over the years, but apparently none > of the fixes were a complete end-to-end solution. > > Of course, it's kind of rediculous that I'm even forced to use > fdisk(1M), just because I'm sitting on two USB disks. > > I'd like to know, why can't I, on sparc, just use format(1M) to > write a VTOC label like on any other disk? > > Why are USB disks treated as "removable" is really beyond me; I > mean, a SCSI disk can in that sense be "removable", because nothing > is stopping me from quiescing the SCSI bus with cfgadm(1M), and > disconnecting the disk(s), all the more so, since in today's day and > age, almost all the servers come with hot swappable SCSI and SATA > bays. > > Why is USB different? > > Even more so, please allow me the luxury of being stupid, and asking > a really stupid question: > > how is it, that the most advanced operating system on the planet, > still does not handle USB properly? All the other operating systems > do so without problems, only Solaris, which, ironically, has the > most competent of the engineers, does not? Is my stupid question > really and completely unfounded? > > > This message posted from opensolaris.org > _______________________________________________ > storage-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/storage-discuss _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
