Odd volume labeling UFS partition

Kaminar

Kaminar

Hi,

I noticed some odd things with volume labeling UFS filesystem. I was trying it on FreeBSD-8.2R. I prepared HDD "ad1" for one slice covers whole HDD with one partition via sysinstall. After slicing and bsdlabeling via sysinstall I have got:

Code: 
# bsdlabel /dev/ad1s1
# /dev/ad1s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  c:  2096577        0    unused        0     0         # "raw" part, don't edit
  d:  2096577        0    4.2BSD        0     0     0

Then I initialized UFS via newfs (not in sysinstall). I add switch -L to get partition with volume name "datadisk":

Code: 
# newfs -UL datadisk /dev/ad1s1d 
/dev/ad1s1d: 1023.7MB (2096576 sectors) block size 16384, fragment size 2048
        using 6 cylinder groups of 183.72MB, 11758 blks, 23552 inodes.
        with soft updates
super-block backups (for fsck -b #) at:
 160, 376416, 752672, 1128928, 1505184, 1881440

After that I've got label "datadisk" not for bsdlabel "d" but for slice "s1":

Code: 
# glabel status
                  Name  Status  Components
ufsid/4e3d65e8f0d63f14     N/A  ad1s1
          ufs/datadisk     N/A  ad1s1

# ll /dev/ufs
total 0
crw-r-----  1 root  operator    0,  85  6 srp 18:03 datadisk  [I][B]--> (ad1s1)[/I][/B]
crw-r-----  1 root  operator    0,  87  6 srp 18:03 datadiskd [I][B]--> (ad1s1d)[/I][/B]


I found that if disk is prepared directly with bsdlabel (not via sysinstall) it works as I expect:

Code: 
# fdisk -I /dev/ad1
******* Working on device /dev/ad1 *******
fdisk: invalid fdisk partition table found
fdisk: Class not found

# bsdlabel -w /dev/ad1s1
# bsdlabel -e /dev/ad1s1
# bsdlabel /dev/ad1s1

# /dev/ad1s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:  2096561       16    unused        0     0
  c:  2096577        0    unused        0     0         # "raw" part, don't edit

Then I changed to this:

Code: 
# bsdlabel /dev/ad1s1
# /dev/ad1s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  c:  2096577        0    unused        0     0         # "raw" part, don't edit
  e:  2096561       16    4.2BSD        0     0     0

I leave offset 16 of partition "e" set by bsdlabel. I continued with initializing UFS:

Code: 
# newfs -UL datadisk /dev/ad1s1e 
/dev/ad1s1e: 1023.7MB (2096560 sectors) block size 16384, fragment size 2048
        using 6 cylinder groups of 183.72MB, 11758 blks, 23552 inodes.
        with soft updates
super-block backups (for fsck -b #) at:
 160, 376416, 752672, 1128928, 1505184, 1881440

The volume was created as I expected only for partition "e":

Code: 
# glabel status
                  Name  Status  Components
ufsid/4e3d671c32125d80     N/A  ad1s1e
          ufs/datadisk     N/A  ad1s1e

# ll /dev/ufs
total 0
crw-r-----  1 root  operator    0,  85  6 srp 18:09 datadisk [B][I]--> (ad1s1e)[/I][/B]


It seems volume label doesn't work correctly when offset of partition is 0.

Could someone explain to me why volume not set to partition when partition offset is 0? And why sysinstall creates partition with offset 0 and bsdlabel normally creates offset 16?
 
After study BSD partition scheme I learned that in slice sector #1 is stored BSD partition table. It is not answer to my question about volume labeling. But the second question is raised. Is it safe to create the first BSD partition with offset 0? At least it can lead to clearing BSD partition table in situation:

# dd if=/dev/zero of=/dev/ad1s1a count=2
 
The first partition on a drive should be a. I'm not certain skipping a, b, and the reserved c will cause a data problem. But if you have FreeBSD partitions on a drive, there's the expectation of a.

And there's the option of not using partitions at all. ad1s1 can hold a filesystem directly.

As far as the offset goes, don't know, sorry.
 
It shouldn't matter if the partition is called a,b or d. But traditionally a is used for the root filesystem and b for swap. Because of this some people choose d as the first 'user' partition.

The first offset (64 for MBR) is used to skip partition tables, bootloaders etc. It's done so tools like Windows' fdisk doesn't destroy your partitions.
 
Yes, but MBR is outside of slice and it is not concerns an offset (used by utility bsdlabel(8)) of BSD partitions placed inside slice. So, if it is right then offset 0 interpreted by bsdlabel(8) (not offset stored in bsdlabel table which is physically written on disk) is the first sector of the slice.

Some times ago I asked similar question about offset of the first BSD partition inside slice. I have not got answer for this problem. Surprisingly, it seems it is dim problem for most users.

Summary of volumes labeling at this moment what I explored:

  1. If you want to get correct volume labeling (/dev/ufs or /dev/ufsid) within newfs(8), you should use offset 16 of the first BSD partition inside slice. It also respects information from man page bsdlabel(8) (see par. "offset": The first partition should start at offset 16, because the first 16 sectors are reserved for metadata.). Unfortunately sysinstall creates the first BSD partition with offset 0.
  2. If slice contains more then one BSD partition then volume labeling works right even offset of the first BSD partition is 0.
  3. If slice contains only one BSD partition at offset 0 and this BSD partition is shorter then slice length then it seems volume labeling works correctly.
  4. If the first BSD partition inside slice has offset 0 then volume labeling mismatched in some situations. And there is possibility to clear BSDlabel table, because the first BSD partition with offset 0 covers metadata. There is also question if it is safe. I don't hear somebody reported any data corruption, but it is not proof of data harmless.

Do somebody know about free available documentation which detail describes UFS2 including volume labeling in FreeBSD?
 
SirDice said:
It shouldn't matter if the partition is called a,b or d. But traditionally a is used for the root filesystem and b for swap.
Click to expand...
I learned the hard way that the boot manager will fail if 'a' is swap and not the root partition. The documentation called it a only a tradition so I didn't take it seriously enough. I ended up installing GRUB just so that I could boot the system.
 
The question over the need for the 16 block offset is one I'd love answered too. I know gpart(8) doesn't automatically set a 16 block offset for the first partition in a BSD label, and it's supposedly the "new" way of partitioning in FreeBSD.

Kaminar's observations seem to show unexpected behaviour...
 
You must log in or register to reply here.
Back
Top