SUMMARY: determining filesystem type

From: Brett Lanham <>
Date: Thu Nov 14 2002 - 10:40:28 EST
Thanks to Mike Kail, Stevenm Ruby, Valeriy, Steve OBrien, scb1, Jay Lessert,
Brooke King, Zaigui Wang, Dennis Martens, Rick McKinney, Sergey Tsyganenko,
Marco, Johan Hartzenberg, and Osama Ahmed.

Well after many emails and trying various commands I still have not been
able to mount the slices.  

Almost everyone pointed me to 'fstyp' which is exactly what I was looking
for except that it reported the slice as unknown.  BTW 'fstyp' tells what
the filesystem type if for known filesystems in case that isn't obvious.

Another suggestion was to try 'newfs -Nv' and 'mkfs -m' which would report
to me what the command line used to create the filesystem was but both
reported the filesystem type as ufs.  mkfs does report 'not currently a
valid filesystem - bad superblock'.  After doing some searching I found that
the superblock is stored in multiple locations on the slice so I can use
'newfs -N' on the raw device (/dev/rdsk) and determine what the other
locations for the superblock are and then use 'fsck -F ufs -o b=#', where #
is an alternate location for the superblock as reported by newfs -N, to
restore the superblock.  I tried this with all the locations for the
superblock and I got the same message each time.

I did find something about this error being either because no filesystem had
been created or an weird unknown filesystem is there, which puts me right
back where I started.  I went ahead and did a newfs on the slice and as
expected it works just fine, except that I lost all data that might have
been there.

Also others suggested that maybe these slices were part of some volume
management like veritas of SDS.  I was told that there wouldn't be a slice 0
(s0) if these drives were part of veritas volume but I've looked at
partition table info while in format and I'm relatively certain there is an
s0 as well as s1, s2, and s6.  s2 of course representing the entire disk but
none of the other slices overlap or anything strange.  Also for more
research into the volume mgmt theory I ran 'prtvtoc' which is used to report
info on disk geometry and partitioning.  I was told that a tag of 14 or 15
on any of the slices would indicate previous involvement with volume mgmt
but none of the slices on any of the drives had these tags. here is the
output of that command in case anyone sees something I'm missing.

# prtvtoc /dev/rdsk/c2t8d0s2
* /dev/rdsk/c2t8d0s2 partition map
* Dimensions:
*     512 bytes/sector
*     107 sectors/track
*      27 tracks/cylinder
*    2889 sectors/cylinder
*   24622 cylinders
*   24620 accessible cylinders
* Flags:
*   1: unmountable
*  10: read-only
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      2    00          0    262899    262898
       1      3    01     262899    262899    525797
       2      5    01          0  71127180  71127179
       6      4    00     525798  70601382  71127179

I believe at this point I'm just going to repartition these drives and newfs
them and be done with it.  I would have liked to mounted them and checked
them out but it looks like that is not going to happen.  Thanks to everyone
who replied and the rest of the list for your help.


> -----Original Message-----
> From: Brett Lanham []
> Sent: Wednesday, November 13, 2002 4:01 PM
> To: Sunmanagers (E-mail)
> Subject: determining filesystem type
> I've got a D1000 storage device that I'd like to be able to 
> mount the slices
> and see what is on them but I keep getting the message:
> 	# mount /dev/dsk/c2t9d0s0 /mnt/tmp
> 	mount: /dev/dsk/c2t9d0s0 is not this fstype.
> I've tried mount with -F pcfs thinking maybe these drives 
> were formatted
> with a pc filesystem but that gives me the same message. I've 
> also tried
> with -F ufs but that is what should be happening by default.  
> Is there any
> way to determine what the filesystem used on those slices 
> are? or get them
> mount some way?  Thanks.
> Brett Lanham
> _______________________________________________
> sunmanagers mailing list
sunmanagers mailing list
Received on Thu Nov 14 10:45:12 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:58 EST