Changing fstype in disklabel (ext2fs -> 4.2BSD)

[soderlund]

Hi,

• I created an FFS2 (UFS2) filesystem in FreeBSD (/dev/wd1n in OpenBSD).
• It shows up as ext2fs in OpenBSD's disklabel, but I can mount it just fine with mount(8) (# mount -t ffs) and everything appears to work like it should. I can read and write to it, % df shows the correct size and it has a (empty) .snap directory.
• Problem: When I put it in /etc/fstab, it will not mount at boot because the fstype in fstab (ffs) does not equal the fstype in disklabel (ext2fs).

This is the relevant line in /etc/fstab:

fb4c0492275ba2e5.n /dataufs ffs rw,softdep,nodev,nosuid 0 0

This is my disklabel (output of # disklabel wd1):

# /dev/rwd1c:
type: ESDI
disk: ESDI/IDE disk
label: WDC WD3200AAKX-0
duid: fb4c0492275ba2e5
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 38913
total sectors: 625142448
boundstart: 50782208
boundend: 99610624
drivedata: 0

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
  a:          2103744         50782208  4.2BSD   2048 16384    1 # /
  b:          4192993         52885952    swap                   # none
  c:        625142448                0  unused
  d:          1060256         57078976  4.2BSD   2048 16384    1 # /home
  e:         10474368         58139232  4.2BSD   2048 16384    1 # /tmp
  f:          5237184         68613600  4.2BSD   2048 16384    1 # /var
  g:         25759840         73850784  4.2BSD   2048 16384    1 # /usr
  i:          1951744             2048  ext2fs
  j:         48234438          1953819 unknown
  k:          3903488         99612672 unknown
  l:         13670400        103518208  ext2fs
  m:        390623232        117190656  ext2fs                   # /dataext
  n:         19529728        507815936  ext2fs                   # /dataufs
  o:           974848        527347712  ext2fs
  p:          3903488        528324608  ext2fs

(I added a-g manually during the install. i-p have been added automatically by OpenBSD. Also there are more than 16 partitions.)

Obviously I should just change "ext2fs" to "4.2BSD" with # disklabel -e wd1. That is:

Before:

  n:         19529728        507815936  ext2fs                   # /dataufs

After:

  n:         19529728        507815936  4.2BSD                   # /dataufs

When I make this change, disklabel says "too few fields" and asks if I want to edit the file again. disklabel does not complain about too few fields when I revert it back to "ext2fs".

Looking at the other entries with fstype=4.2BSD (/, /home and so on), there are indeed 3 more fields (fsize, bsize and cpg).

Questions:

1. Can I ignore the warning about too few fields?
2. fsize, bsize and cpg are missing -- are these the values printed by # dumpfs /dataufs?
3. How do I find out cpg (it is not shown by dumpfs)?

• fsize = block fragment size (1024 according to dumpfs)
• bzize = block size (8192 according to dumpfs)
• cpg = cylinders per group (???)

I could of course put # mount -t ffs -o ... /dev/wd1n /dataufs in rc.local, but I want to do it properly.

One more thing: it is my understanding that the disklabels are only seen by OpenBSD. So any changes I make to /dev/wd1n (/dataufs) in disklabel -- such as changing the fstype -- will only affect how OpenBSD sees the disk; it will not change any data on the disk or affect FreeBSD (FreeBSD is on /dev/wd1j, and FreeBSD also uses the /dataufs partition). Is that correct?

Reflecting on why this happens, I find this behavior a little strange. When the operating system boots, doesn't it just read /etc/fstab and call # mount on all the filesystems with the specified options? Yet # mount succeeds and /etc/fstab fails. So when the system boots, there must be an extra check that compares the filesystem type (in fstab) with the information in disklabel, and refuses to mount if they are not equal.

[jggimi]

Hello, and welcome.

It's not clear to me how a FreeBSD partition ended up in your OpenBSD disklabel as ext2.

For those architectures that use MBRs -- among them amd64 and i386 -- this diagram shows a typical sector layout for drive sd0. The disklabel partition 'c' is used for the whole drive, but only a part of the drive may be used for the OpenBSD area, which is MBR partition type 0xA6.*

                  biosboot
                     :
   MBR               : disklabel
    :                :     :
 0  :  1          64 :  65 :  66
 |=====|==========|=====|=====|===...===|====...===|==================>
 |                |
 |                -- sd0a -------------------------------->
 |                |       (unused)      (superblock)   ...
 |                |
 |                -- OpenBSD area ----------------------------------->
 |
 -- sd0c ------------------------------------------------------------>

You can also change the partition type with the -E option of disklabel(8), and it should fill in the FFS configuration fields based on the defaults.

You will find the cpg value on the 11th line of your dumpfs(8) output.

* diagram courtesy of naddy@ and otto@ in http://marc.info/?t=141507506600001&r=1&w=2

[soderlund]

Thank you.

Originally Posted by jggimi

It's not clear to me how a FreeBSD partition ended up in your OpenBSD disklabel as ext2.

Sorry, I mean I created the UFS2 filesystem on FreeBSD (with newfs). The partition was created with Parted on Linux. It's a "logical" MBR partition, it's not inside the FreeBSD slice.

You will find the cpg value on the 11th line of your dumpfs(8) output.

There is no cpg field anywhere in the output. Is it called something else? I figure it must be 1 or a small integer. Here is the output uf # dumpfs /dev/wd1n (excluding cg 0-249):

magic   19540119 (FFS2) time    Sun Nov  9 15:14:58 2014
superblock location     65536   id      [ 5380a30b 6c19f1b4 ]
ncg     250     size    9764864 blocks  8536788
bsize   8192    shift   13      mask    0xffffe000
fsize   1024    shift   10      mask    0xfffffc00
frag    8       shift   3       fsbtodb 1
minfree 8%      optim   time    symlinklen 120
maxbsize 8192   maxbpg  1024    maxcontig 16    contigsumsize 16
nbfree  1063786 ndir    28      nifree  4895926 nffree  57
bpg     4892    fpg     39136   ipg     19584
nindir  1024    inopb   32      maxfilesize     8804691443711
sbsize  2048    cgsize  8192    csaddr  4984    cssize  4096
sblkno  72      cblkno  80      iblkno  88      dblkno  4984
cgrotor 51      fmod    0       ronly   0       clean   1
avgfpdir 64     avgfilesize 16384
flags   soft-updates
fsmnt   /dataufs
volname         swuid   0

[jggimi]

Ah, you're using FFS 2, rather than FFS 1. That's why cpg does not appear in your dumpfs output.

FFS 2 is recommended only for filesystems above 1TB in size. There is no advantage to using FFS 2 for small partitions with OpenBSD. Your partition is 19529728 512-byte sectors, which is just over 9 GB.

[comet--berkeley]

Originally Posted by jggimi

...
There is no advantage to using FFS 2 for small partitions with OpenBSD. ...

Try this command on a FFS 1 partition and then on a FFS 2 partition:

$touch -t 203801201234 y2k38-test

FFS 2 partitions support 64-bit timestamps and FFS 1 partitions do not.

[soderlund]

Hmm. I don't expect this disk to live for 24 more years (10 years is my current record), but let's figure out how to do it with FFS2 anyway. It could be a 2TB partition for someone searching in the future.

fsize and bsize are known but cpg does not exist? So a wild guess is that I should fill in fsize and bsize and omit cpg, like this:

#                size           offset  fstype [fsize bsize  cpg]
  n:         19529728        507815936  4.2BSD   1024  8192      # /dataufs

It still says:

disklabel: line 31: too few fields
re-edit the label? [y]:

[jggimi]

Originally Posted by comet--berkeley

FFS 2 partitions support 64-bit timestamps and FFS 1 partitions do not.

OK. Thanks! I'd forgotten about the 64-bit atime/mtime/ctime fields.

If I recall correctly, FFS 2 partitions are (currently) not bootable. When that becomes possible, you'll need to manage a root filesystem transition from the RAMDISK kernel, or you'll need to reinstall, in order to have an FFS 2 boot partition.

Originally Posted by soderlund

It could be a 2TB partition for someone searching in the future.

The recommendation by the Project is to use the defaults unless you planned to grow above the FFS 1 limit in the future. This is because growfs(8) does not support switching filesystem types. See the misc@ mailing list discussion that started here.

So a wild guess is that I should fill in fsize and bsize and omit cpg...

The disklabel program doesn't know you're going to use -O 2 with your newfs command. Either apply the default for that size volume (cpg 1), or use the -E option of disklabel(8) as I'd recommended above. If you use the -E option, the built-in editor's m [part] command will fill in these values for you.

[IdOp]

Originally Posted by soderlund

The partition was created with Parted on Linux. It's a "logical" MBR partition, it's not inside the FreeBSD slice.

I suspect this is the root cause of where the ext2 came from. I'm not very familiar with parted, but the similar program Linux' fdisk does set the partition type to Linux by default. Likely GNU parted does the same? It might be a good idea to change that type as appropriate. Although that won't fix the consequences you see now, it may prevent similar ones in the future.

[soderlund]

I did like you said and it works now, jggimi. It's mounted at boot from fstab with no complaints. Thanks a lot for the help.

Originally Posted by IdOp

I suspect this is the root cause of where the ext2 came from. I'm not very familiar with parted, but the similar program Linux' fdisk does set the partition type to Linux by default. Likely GNU parted does the same? It might be a good idea to change that type as appropriate. Although that won't fix the consequences you see now, it may prevent similar ones in the future.

Yes, it must be. I have a similar problem with a USB drive. I created a single ext2 partition on it using cfdisk and mke2fs, and it always shows up as vfat (which was the original filesystem). It works as it should though (permissions are preserved, filenames are case sensitive and there is a lost+found), as long as you remember to mount it as ext2. This led me to believe that the reported filesystem type is just a semi-accurate hint displayed to the user which is not used for anything by the system, but I see now that I should fix it.