Hello! I am trying to understand an odd behaviour in the Berkeley Fast File System as implemented in both NetBSD and OpenBSD. My main concern is not getting a workaround for this problem (hopefully, I found one) but understanding if there are hidden issues than can damage files stored in these shared filesystems in the future.
The scenario is the next one: I have three USB flash memory drives and an external USB HDD (a Plextor PX-PH08U). I want to make ffs filesystems on at least two of the flash memory drives and the HDD to share data between my laptop (running NetBSD) and three computers (running OpenBSD). These machines are running the latest stable releases of NetBSD and OpenBSD. All software is relatively updated (but I am not tracking -stable in either NetBSD or OpenBSD). By now, I will refrain using ffs2 filesystems as support for these new filesystems is not available in OpenBSD yet. (this was my filesystem choice when sharing these drives between both OSes was not an issue for me.) I will stay at ffs until ffs2 is available in OpenBSD. The problem: After doing the usual steps to set up a new disk in OpenBSD: # fdisk -i sd0 # disklabel -e sd0 (setting up the disk partition as 4.2BSD) # newfs sd0a (by the way, is the MBR *required* on i386 architectures when there is a single non-bootable primary partition on the drive? Can it be a problem when sharing these drives with non-i386 architectures? What about endianess behaviour in ffs/ffs2 in different architectures?) ...I see this BSD disklabel on OpenBSD with one of the flash memory drives: # Inside MBR partition 3: type A6 start 32 size 2007008 # /dev/rsd0c: type: SCSI disk: SCSI disk label: USB Flash Memory flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 980 total sectors: 2007040 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a: 2007008 32 4.2BSD 2048 16384 323 # Cyl 0*- 979 c: 2007040 0 unused 0 0 # Cyl 0 - 979 All is fine, I can mount and use that drive. But NetBSD is unable to identify the HDD. This is the way NetBSD reads the disklabel (the "label" field and disk partitions are certainly wrong): # /dev/rsd0d: type: SCSI disk: mydisk label: fictitious flags: removable bytes/sector: 512 sectors/track: 32 tracks/cylinder: 16 sectors/cylinder: 512 cylinders: 3920 total sectors: 2007040 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize cpg/sgs] d: 2007040 0 unused 0 0 # (Cyl. 0 - 3919) h: 2007008 32 unknown # (Cyl. 0*- 3919) disklabel: boot block size 0 disklabel: super block size 0 What I am doing wrong? Why is the disk geometry different on the output of each OS? When I make these filesystems in NetBSD I can see them and use them in OpenBSD too. But it certainly does not assure that problems will not happen in the future. Are there known incompatibilities between NetBSD's ffs and OpenBSD's ffs? Should I open a PR? Can it be related with the third partition in NetBSD? (usually, NetBSD has a partition that fills the entire disk, and another partition that fills the part of the disk that is being used by NetBSD.) By the way, when will ffs2 be available in OpenBSD? From the changelogs I see that there is some work being done in preparation for ffs2, these are excellent news. Thanks in advance for any help! Igor.
