The original question :
> I have two 2Go Sun disk (previously used under SunOS4) attached to my AS1000A
> running 3.2F. They are correctly recognized at boot in the console as SEAGATE
> SCSI disks. I created the devices with MAKEDEV and it seems ok :
>
> root_at_silk:/# file /dev/rrz[0-2]a
> /dev/rrz0a: character special (8/0) SCSI #0 RZ28D disk #0 (SCSI ID #0)
> /dev/rrz1a: character special (8/1024) SCSI #0 RZxx disk #8 (SCSI ID #1)
> /dev/rrz2a: character special (8/2048) SCSI #0 RZxx disk #16 (SCSI ID #2)
>
> First question: what does the #8 and #16 mean?
>
> root_at_silk:/# disklabel -r rz1
> Disk is unlabeled or, /dev/rrz1a does not start at block 0 of the disk
>
> The idea behind this is that this disk contains valid data on one partition
> that I would like to keep there while using the remaining (currently free)
> space as a UFS partition on the AlphaServer. I don't need to read the data on
> the SunOS partition, I just want to use the remaining space without loosing
> the data. The second disk is completely free.
>
> Second question: I know the idea is weird but is it possible? if so, what am
> I doing wrong?
Thanks to :
john_at_iastate.edu (John Hascall)
alan_at_nabeth.cxo.dec.com (Alan Rollow - Dr. File System's Home for Wayward Inodes.)
szgyula_at_skysrv.Pha.Jhu.EDU (Gyula Szokoly)
The most complete answer came from Alan Rollow :
> The file command is echoing one of the fields in data structure
> filled in by the DEVIOCGET I/O control. That field happens to
> have the knowledge that SCSI-2 supports 8 targets per bus and
> 8 logical units per target. So, internally the driver uses a
> device numbering that has LUN 0 every 8 devices. Unfortunately,
> the over system device naming method doesn't allow for LUNs
> easily and this causes some problems, but nothing severe.
>
> As for the disklabel, I don't recall what the -r option does
> by itself. My best guess, without the manual page in front
> of me is that tries to read the label from the disk into
> memory. So, the message telling you that the disk doesn't
> have a label. This shouldn't be a surprising with the disk
> coming from a Sun system. Disk labels and their attendent
> partition tables are operating system specific and OSF made
> no effort to support Sun's VTOC.
>
> If Sun's label lives in the first sector or the disk, then
> you can overwrite their label with ours and repartition to
> protect the data. Unfortunately, that loses the Sun label
> and it will have to be recreated if you move the disk back.
> If Sun doesn't use the first sector (which is likely, if
> the first partition of interest starts at sector 0 and is
> a Berkeley Fast File System) then you can safely write the
> Digital UNIX label and partition as desired.
>
> The FFS typically reserves the first 16 sectors of a partition
> as a boot block.
I finally decided it was much simpler to juste use the free disk and let the
other one as is (because those disks won't say in the AlphaServer more than one
month) :-)
I'm afraid the Sun partition is in fact a Solaris one (at least I was told so),
so I don't know if I can assume FFS. Nevermind, if I can find some free time
and try Alan's suggestion of overwriting the Sun label, I'll post the results
here.
--
Thomas.Parmelan_at_efrei.fr -- Linux: the Penguin is FREE! -- tom_at_ankh.fr.EU.org
Usenet Canal Historique <URL:http://web.efrei.fr/~parmelan/>
Received on Mon Sep 09 1996 - 19:33:45 NZST