format and df -k not jibing..?

[DBPW]

Why does the output of the format command show that partitition 4 is
"unassigned" even though it is actually the /mycompany/usr partition as
shown in df -k?

This is a new Solaris 10 install.

format of c1t0d0:
Part Tag Flag Cylinders Size Blocks
0 root wm 1649 - 3661 9.77GB (2013/0/0)
20484288
1 swap wu 0 - 1648 8.00GB (1649/0/0)
16780224
2 backup wm 0 - 14086 68.35GB (14087/0/0)
143349312
3 var wm 3662 - 5272 7.82GB (1611/0/0)
16393536
4 unassigned wm 5273 - 7285 9.77GB (2013/0/0)
20484288
5 unassigned wm 0 0 (0/0/0)
0
6 unassigned wm 0 0 (0/0/0)
0
7 unassigned wm 7286 - 7287 9.94MB (2/0/0)
20352

#> df -k
Filesystem kbytes used avail capacity Mounted on
/dev/md/dsk/d0 10086988 5925494 4060625 60% /
/devices 0 0 0 0% /devices
ctfs 0 0 0 0% /system/contract
proc 0 0 0 0% /proc
mnttab 0 0 0 0% /etc/mnttab
swap 11438184 968 11437216 1%
/etc/svc/volatile
objfs 0 0 0 0% /system/object
fd 0 0 0 0% /dev/fd
/dev/md/dsk/d6 8072333 92519 7899091 2% /var
swap 11571184 133968 11437216 2% /tmp
swap 11437264 48 11437216 1% /var/run
/dev/md/dsk/d9 10086988 34245 9951874 1% /mycompany/usr

Thanks Gurus or WBG's,
DBPW

[Dave]

it's because when the partition was created, the mount point was not
input into format to be saved on the disk label.

[Darren Dunham]

DBPW <mmc...@gmail.com> wrote:
> Why does the output of the format command show that partitition 4 is
> "unassigned" even though it is actually the /mycompany/usr partition as
> shown in df -k?

> This is a new Solaris 10 install.

> format of c1t0d0:
> Part Tag Flag Cylinders Size Blocks
> 0 root wm 1649 - 3661 9.77GB (2013/0/0)
> 20484288
> 1 swap wu 0 - 1648 8.00GB (1649/0/0)
> 16780224
> 2 backup wm 0 - 14086 68.35GB (14087/0/0)
> 143349312
> 3 var wm 3662 - 5272 7.82GB (1611/0/0)
> 16393536
> 4 unassigned wm 5273 - 7285 9.77GB (2013/0/0)
> 20484288

Because the 'Tag' field is an ancient concept, unused by almost
everything today, but it is still shown by 'format' and 'prtvtoc'. It
is a 4 byte field that can only represent a limited number of items.
Only a few OS filesystems will have a matching tag name. You have to
pick something else (like 'unassigned') for any others.

You can see the possibilities in /usr/include/sys/vtoc.h.

As long as you don't use 'root', the system won't care which one you
pick.

--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

[DBPW]

Very interesting...thanks! I love it when I understand something that
previously was neither intuitive or logical to me.

[Darren Dunham]

Darren Dunham <ddu...@redwood.taos.com> wrote:
> You can see the possibilities in /usr/include/sys/vtoc.h.

> As long as you don't use 'root', the system won't care which one you
> pick.

And for clarification since I got some email, the running system almost
certainly wouldn't care at all even if you did use root. I only know of
two things that actually care about the contents of the 'Tag' fields.

1) Suninstall upgrades
When the installer runs, it looks at the local disks for 'root' tagged
slices and sees if they are a real root filesystem, opens any
/etc/vfstab in them and determines if that describes an upgradeable
system. If you have multiple 'root' tagged slices, I think it gets
confused and refuses to upgrade. That's what I was referring to with my
last statement. I have run dual-OS SPARC systems with separate root
slices (each 'root' tagged) with no issues.

2) Veritas Volume Manager
All veritas initialized disks of type 'sliced' and a VTOC label use tags
'14' and '15' to represent the private and public regions (easier to see
in 'prtvtoc' than in 'format'). If those tags aren't present, VxVM will
not automatically find and recognize the disk as a valid vxdisk.