Using large (e.g. 1.5 TB) USB hard drives w/ Solaris
Reginald Beardsley
entries that *might* answer my question, I can't read them :-(
I just got a 1.5 TB Seagate USB drive to use for backups. Unfortunately
I'm not able to access the drive from Solaris. It works w/ Windows XP,
but does not work w/ any of the following:
Solaris 10 U5
Solaris 10 U6
OpenSolaris 5/08
fdisk reports "cannot open device"
and dd reports "I/O error" if I try to read from the disk.
However, rmformat -l lists the device (and the size on OpenSolaris)
I've never had a problem before, but the largest drive (USB or SATA)
I've used before is 750 GB.
Can anyone report using a 1.5 TB USB disk w/ Solaris? If so, what are
the details? Conversely is this a known issue?
Thanks,
Reg
Dave
I've not used 1.5 TB, but have used 1.0 TB disks ok.
See this thread which I started after initially having problems.
--
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange' take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.
solx
The process formatting the drive for UFS is very convoluted, I have a
1TB SATA drive in a USB enclosure. These as instructions I sent to my
brother.
1. The drive is detected so that it appears in rmformat -l
2. Create a Solaris partition on the disk, adjust as appropiate
# fdisk /vol/dev/rdsk/c5t0d0/unknown_format
3. Unplug/plug the USB drive
4. Get the drive details
# fdisk -W - /vol/dev/aliases/rmdisk0
* /vol/dev/aliases/rmdisk0 default fdisk table
* Dimensions:
* 512 bytes/sector
* 126 sectors/track
* 255 tracks/cylinder
* 60800 cylinders
*
* systid:
* 1: DOSOS12
* 2: PCIXOS
* 4: DOSOS16
* 5: EXTDOS
* 6: DOSBIG
* 7: FDISK_IFS
* 8: FDISK_AIXBOOT
* 9: FDISK_AIXDATA
* 10: FDISK_0S2BOOT
* 11: FDISK_WINDOWS
* 12: FDISK_EXT_WIN
* 14: FDISK_FAT95
* 15: FDISK_EXTLBA
* 18: DIAGPART
* 65: FDISK_LINUX
* 82: FDISK_CPM
* 86: DOSDATA
* 98: OTHEROS
* 99: UNIXOS
* 101: FDISK_NOVELL3
* 119: FDISK_QNX4
* 120: FDISK_QNX42
* 121: FDISK_QNX43
* 130: SUNIXOS
* 131: FDISK_LINUXNAT
* 134: FDISK_NTFSVOL1
* 135: FDISK_NTFSVOL2
* 165: FDISK_BSD
* 167: FDISK_NEXTSTEP
* 183: FDISK_BSDIFS
* 184: FDISK_BSDISWAP
* 190: X86BOOT
* 191: SUNIXOS2
* 238: EFI_PMBR
* 239: EFI_FS
*
* Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect
191 128 0 1 2 254 63 1023 32130 1953471870
5. Multiple ( Numsect * Bytes per Sector )/ (1024*1024) to get partition
0 and 2 size (100% of drive)
( 1953471870 * 512 )/ 1048576 = 953843MB
6. Create a partition file disk_slice.txt for rmformat
slices: 0 = 0, 953843MB, "wm", "unassigned" :
1 = 0, 0MB, "wu", "unassigned" :
2 = 0, 953843MB, "wm", "backup"
7. Write ufs partition information to Solaris drive partition
# rmformat -b big_one -s disk_slice.txt /vol/dev/aliases/rmdisk0
8. UFS format drive
# newfs /vol/dev/aliases/rmdisk0
9. Drive is automatically mounted as "big_one"
Hope that helps
ITguy
ZFS will take care of all the configuration details for you. Get the
device path from the rmformat command and add to a ZFS pool.
# zpool create -f usb cXtXdX
This example will use the entire disk and automatically mount it at /
usb. To disconnect the disk, run "zpool export usb", and "zpool
import usb" to re-attach.
Reginald Beardsley
[snip]
I'm not using the volume manager, so the syntax is a little different.
but your second step is to run fdisk which is what's failing. But even
w/ the volume manager running, it fails. I just tested U7 w/ similar
results.
Reg
Reginald Beardsley
Nope. Produces the same result that dd does: "I/O error" (on U7 this time)
So either it's a Seagate firmware issue or Solaris doesn't handle USB
drives larger than 1 TB.
A truss of
"dd if=/dev/rdsk/cXtXdX bs=512 count=1 of=/dev/null"
reports an EIO return from the open64() call on the raw device.
It's really not reasonable to expect any operation on the disk to work
if a dd of the first sector fails.
Unfortunately I don't use Windows enough to have any need for a 1.5 TB
NTFS disk :-(
ITguy
I wonder if vold creates a lock on the device that prevents the usual
disk tools from working. Have you tried disabling the SMF "volfs"
service?
> So either it's a Seagate firmware issue or Solaris doesn't handle USB
> drives larger than 1 TB.
I haven't tried one that large myself, but it *should* work ;-)
Reginald Beardsley
>>>>However, rmformat -l lists the device (and the size on OpenSolaris)
>
>
> I wonder if vold creates a lock on the device that prevents the usual
> disk tools from working. Have you tried disabling the SMF "volfs"
> service?
>
One of the first things I do after a new install is turn off volfs. It
seems to be somewhat improved over when it first appeared, but I've
never liked it. In general, volfs is NOT going to interact well w/ a
file system not supported by Solaris. I really don't want volfs to
*help me* by reformating a drive when I plug it in.
In any event, my initial attempts were w/ volfs turned off. Most recent
were w/ it turned on (fresh install of U7) and again after turning volfs
off.
>
>>So either it's a Seagate firmware issue or Solaris doesn't handle USB
>>drives larger than 1 TB.
>
>
> I haven't tried one that large myself, but it *should* work ;-)
I wouldn't have bought the drive if I didn't expect it to work.
solx
Reginald Beardsley
> Reginald Beardsley wrote:
>
> Does the disk have a partition defined on it already?
It's got an NTFS filesystem. However, that's completely irrelevant in
this case. Opening the raw device, open64(), fails w/ EIO. If that
fails then nothing can work.
I suspect that the problem is the classic one of an overflow in a
returned value. At some level the system can interrogate the drive as
demonstrated by rmformat seeing the disk. But farther up the disk
driver stack it falls over.
Bruce Esquibel
> Can anyone report using a 1.5 TB USB disk w/ Solaris? If so, what are
> the details? Conversely is this a known issue?
Interesting question to me considering the day you posted it I was ready
to run out and get one to use on an Opensolaris box I just put together (an
older Dell 400SC).
After not seeing anything good/bad with responses I figured to pull the
trigger and get it anyway.
It doesn't work.
You actually seemed to get more response out of it than I did, rmformat -l
never saw it, with or without the volume manager (/usr/lib/rmvolmgr -s)
running. I did get some messages in /var/adm/messages, the box definetly saw
something.
So after pointing my google finger around, I figured the pre-formatted NTFS
on there may have been part of the problem and hooked the drive up to a Mac
G5, that saw it right away. Using it's disk utility I blew out the NTFS and
partitioned it to the HFS+, Jorurnaled, case-insensitve, strawberry and
whipped cream options.
Putting it back on the Dell, a somewhat interesting message comes up in the
/var/adm/messages now...
Jun 4 16:29:13 opensolaris disk has 2930277168 blocks, which is too
large for a 32-bit kernel
So, hmmm, maybe it'll never work on non-64 bit machines.
I have a few v20z's laying around, maybe over the weekend I'll tinker with
it on there, at least get a Solaris2 partition on it and go back to the Dell
and see what happens.
Like others have mentioned, the others in the Seagate FreeAgent line
(500GB/750GB/1TB) don't seem to have a problem.
Maybe there is a way around the limitation, maybe not. It does seem to be
with the kernel, if I'm looking at the logs right, these are all the
messages when you plug it into the usb port...
Jun 4 16:29:14 opensolaris unix: [ID 665567 kern.warning] WARNING:
kstat_create('sd', 1, 'fm'): namespace collision
Jun 4 16:29:14 opensolaris scsi: [ID 107833 kern.warning] WARNING:
/pci@0,0/pci1028,162@1d,7/storage@3/disk@0,0 (sd1):
Jun 4 16:29:14 opensolaris disk has 2930277168 blocks, which is too
large for a 32-bit kernel
If anything else comes up with my poking around, will post it.
-bruce
b...@ripco.com
Casper H.S. Dik
>Jun 4 16:29:13 opensolaris disk has 2930277168 blocks, which is too
>large for a 32-bit kernel
>So, hmmm, maybe it'll never work on non-64 bit machines.
Very possible. A 32 bit kernel uses a 32bit "disk address" to address
512 byte blocks. I think it's signed too, which leaves you with
a maximum size of a disk of 1099511627776 bytes. (Slightly more than
a marketing TB)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Reginald Beardsley
> Bruce Esquibel <b...@ripco.com> writes:
>
>
>>Jun 4 16:29:13 opensolaris disk has 2930277168 blocks, which is too
>>large for a 32-bit kernel
>
>
>>So, hmmm, maybe it'll never work on non-64 bit machines.
>
>
> Very possible. A 32 bit kernel uses a 32bit "disk address" to address
> 512 byte blocks. I think it's signed too, which leaves you with
> a maximum size of a disk of 1099511627776 bytes. (Slightly more than
> a marketing TB)
>
> Casper
FWIW I'm using a 64 bit kernel:
sun_x86%rhb {291} isainfo -kv
64-bit amd64 kernel modules
so the problem extends beyond the 32 bit kernel. I'm assuming that it's
probably the result of a 32 bit signed value being used somewhere, but I
don't know dtrace well enough to chase it down.
truss tells me that open64() returns EIO when I try to read the first
sector of the raw device w/ dd.
In OpenSolaris 5/08, rmformat -l reports the disk as ~ 1400 GB, so at
least at some level the system is able to talk to the drive.
Here's what /var/adm/messages (on Sol10 U5) has in my case:
May 29 15:03:39 u20 genunix: [ID 408114 kern.info]
/pci@0,0/pci108e,5347@2,1/storage@3 (scsa2usb0) offline
May 29 15:04:01 u20 usba: [ID 912658 kern.info] USB 2.0 device
(usbbc2,3001) operating at hi speed (USB 2.x) on USB 2.0 roo
t hub: storage@3, scsa2usb0 at bus address 2
May 29 15:04:01 u20 usba: [ID 349649 kern.info] Seagate
FreeAgent 2GEVV7XL
May 29 15:04:01 u20 genunix: [ID 936769 kern.info] scsa2usb0 is
/pci@0,0/pci108e,5347@2,1/storage@3
May 29 15:04:01 u20 genunix: [ID 408114 kern.info]
/pci@0,0/pci108e,5347@2,1/storage@3 (scsa2usb0) online
May 29 15:04:12 u20 scsi: [ID 193665 kern.info] sd1 at scsa2usb0: target
0 lun 0
May 29 15:04:12 u20 genunix: [ID 936769 kern.info] sd1 is
/pci@0,0/pci108e,5347@2,1/storage@3/disk@0,0
May 29 15:04:12 u20 genunix: [ID 408114 kern.info]
/pci@0,0/pci108e,5347@2,1/storage@3/disk@0,0 (sd1) online
May 29 15:04:44 u20 genunix: [ID 408114 kern.info]
/pci@0,0/pci108e,5347@2,1/storage@3/disk@0,0 (sd1) offline
May 29 15:04:44 u20 last message repeated 1 time
Reg
Bruce Esquibel
> FWIW I'm using a 64 bit kernel:
> sun_x86%rhb {291} isainfo -kv
> 64-bit amd64 kernel modules
I don't know then.
I don't think the tests on the v20z I was going to do will work out, I'm
guessing the usb port is dead or something.
However, I did plug it into an 280r (sparc based, running some version of
solaris 10) and after doing the regular voodoo with volfs and rmformat, it
did come up and seemed to work fine. The 280r just has usb 1.0 but dumping a
few small files to it worked with no errors.
Came out to like 1435GB usable space.
Oh, here it is...
Solaris 10 10/08 s10s_u6wos_07b SPARC
Anyway, I have access to some other v20z's but will be a while until I can
get to them. I'm going to rule out getting it to work on 32bit machines
anyway at this point.
I'm not sure where this dumped from but maybe it'll be handy to someone
else...
# prtvtoc /dev/dsk/c3t0d0
* /dev/dsk/c3t0d0 (volume "test1") partition map
*
* Dimensions:
* 512 bytes/sector
* 2930277168 sectors
* 2930277101 accessible sectors
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 2 00 34 262144 262177
1 3 01 262178 262144 524321
6 4 00 524322 2929736428 2930260749
8 11 00 2930260750 16384 2930277133
-bruce
b...@ripco.com
Reginald Beardsley
Bruce,
That's actually useful information. What was your incantation for volfs
& rmformat? I normally just use fdisk and newfs w/ volfs turned off.
Thanks,
Reg
Bruce Esquibel
> That's actually useful information. What was your incantation for volfs
> & rmformat? I normally just use fdisk and newfs w/ volfs turned off.
No great secrets but you can't do much with fdisk until you get something
back from "rmformat -l", which is the challenge sometimes.
The problem is it's not consistant. With getting usb drives to be seen, I
agree, volfs gets in the way more than it doesn't so shutting that off is
still generally a good idea.
But also, before the drive gets plugged in, I usually run devfsadm -C to
clear out the old /dev/rdsk stuff. But after that, when you do plug the
drive in, it's been a mixed bag of rituals. Sometimes they show up right
away, sometimes it needs a reboot, sometimes just pulling/plugging the usb
in works. I'm guessing there is just variances with the eide (or sata) to
usb module in the external cases.
I dunno, the whole issue is sort of confusing. A friend of mine I was
talking to the other day claimed to have the same unit (Seagate FreeAgent
1.5TB) hanging on a Ubuntu based desktop which he knows is 32bit only. Comes
up a little short, like 1290GB but didn't have any issues getting it to
work.
I also started to doubt the usb port on the v20z being bad, like I said on
that one I assumed the port was defective because I couldn't get anything at
all (messages in /var/adm/messages) and nothing with rmformat. After the
dust settled a bit with drive swaps, I stuck in a Maxtor usb drive (500GB)
and it showed up right away. Hmmm.
Next time I see a sale on the raw sata's, will grab one of those and see
what happens with all the usb stuff out of the way.
-bruce
b...@ripco.com
Reginald Beardsley
> Reginald Beardsley <us...@example.net> wrote:
>
>
>>That's actually useful information. What was your incantation for volfs
>>& rmformat? I normally just use fdisk and newfs w/ volfs turned off.
>
>
> No great secrets but you can't do much with fdisk until you get something
> back from "rmformat -l", which is the challenge sometimes.
>
> The problem is it's not consistant. With getting usb drives to be seen, I
> agree, volfs gets in the way more than it doesn't so shutting that off is
> still generally a good idea.
>
> But also, before the drive gets plugged in, I usually run devfsadm -C to
> clear out the old /dev/rdsk stuff. But after that, when you do plug the
> drive in, it's been a mixed bag of rituals. Sometimes they show up right
> away, sometimes it needs a reboot, sometimes just pulling/plugging the usb
> in works. I'm guessing there is just variances with the eide (or sata) to
> usb module in the external cases.
>
> I dunno, the whole issue is sort of confusing. A friend of mine I was
> talking to the other day claimed to have the same unit (Seagate FreeAgent
> 1.5TB) hanging on a Ubuntu based desktop which he knows is 32bit only. Comes
> up a little short, like 1290GB but didn't have any issues getting it to
> work.
>
I specifically turn off volfs to avoid that sort of stuff. I just plug
in the drive, switch to the root window, mount and go to work. Making a
filesystem w/ newfs requires -s which is one of the reasons for running
fdisk. I've never had a problem w/ rmformat seeing a drive. I have had
problems w/ volfs wanting to reformat drives w/ multiple partitions
(e.g. Solaris & FAT32)
I suspect the problem is in the scsa2usb layer.
I'll give Linux a spin sometime and see what it has to say.
Have Fun!
Reg