A request for unnested UFS implementation in MBR

[Bruce Evans]

On Mon, 9 Jul 2018, Gary Palmer wrote:

> On Mon, Jul 09, 2018 at 03:05:35AM +0530, Manish Jain wrote:
>> ...
>> I will reply to all the answers (which accumulated as I had a very nice
>> long sleep, thank you) to this thread here.
>>
>> This is what I get currently applying gpart to my USB pen drive:
>>
>> /root <<: gpart create -s MBR da0
>> da0 created
>> /root <<: gpart add -t linux-data -s 1G da0
>> da0s1 added
>> /root <<: gpart add -t freebsd-ufs -s 1G da0
>> gpart: Invalid argument # WHY ?
>
> As I said in my email, freebsd-ufs is a GPT ID.  MBR has a very
> restricted set of what is considered valid - from memory it's a single
> byte.  That means freebsd-swap, freebsd-zfs, freebsd-ufs, etc aren't
> valid.
>
>> It currently is a real bother having to create UFS, with a whole lot of
>> extra commands:
>>
>> /root <<: gpart add -t freebsd -s 1G da0
>> da0s2 added
>> /root <<: gpart create -s BSD da0s2
>> da0s2 created
>> /root <<: gpart add -t freebsd-ufs da0s2
>> da0s2a added
>
> There is nothing forcing you to create the BSD label
>
> # mdconfig -s 512m
> md0
> # gpart create -s MBR md0
> md0 created
> # gpart add -t freebsd md0
> md0s1 added
> # newfs /dev/md0s1
> /dev/md0s1: 512.0MB (1048560 sectors) block size 32768, fragment size 4096
>        using 4 cylinder groups of 128.00MB, 4096 blks, 16384 inodes.
> super-block backups (for fsck_ffs -b #) at:
> 192, 262336, 524480, 786624
> # mount /dev/md0s1 /mnt

What is all this messing around with gpart?  ffs works on any seekable file,
and so does newfs.  A unpartitioned disk is the easiest case:

Script started on Mon Jul  9 11:51:49 2018
ttyv1:root at besplex:/tmp/u5> mdconfig -a -t malloc -s 512k
md0
ttyv1:root at besplex:/tmp/u5> gpart
bash: gpart: command not found  # gpart doesn't exist on my de-geomed systems
ttyv1:root at besplex:/tmp/u5> newfs /dev/md0
/dev/md0: 0.5MB (1024 sectors) block size 16384, fragment size 2048
 	using 1 cylinder groups of 0.50MB, 32 blks, 64 inodes.
super-block backups (for fsck -b #) at:
  160
ttyv1:root at besplex:/tmp/u5> fsck_ffs /dev/md0
** /dev/md0
** Last Mounted on 
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
2 files, 2 used, 189 free (21 frags, 21 blocks, 11.0% fragmentation)
ttyv1:root at besplex:/tmp/u5> mdconfig -d -u 0
ttyv1:root at besplex:/tmp/u5> exit

Script done on Mon Jul  9 11:52:24 2018

If the device has to be partitioned starting with an MBR, then things get
complicated.  I avoid using EBRs except for testing them when I implemented
them for FreeBSD in ~1994.  FreeBSD's fdisk can't create EBRs and is hard
enough to use for MBRs.

If you want simplicity, then don't partition the disk.  This requires some
magic for booting.  fdisk generates a fake MBR the same as in ~1992 where
it was used more before proper MBR partitioning was implemented.  Newer
BIOSes might have problems with the fake MBR.

I partition all disks except floppies and cd/dvd's and virtual (md) ones.
Not partitioning worked better with smaller disks.  Now with multi-terabyte
disks, partitions are more needed.  However, with large disks there is
more space to get lost in if you have a complicated partitioning scheme.

>> The extra commands mean that when a user wants to quickly put a
>> partition on a disk of any kind, it is much easier using Ext2.
>>
>> If the original command (highlighted with WHY ?) could succeed as such
>> (or perhaps with a slight alteration: gpart add -t ufs -s 1G da0), UFS
>> becomes as convenient as Ext2 for general purpose usage.
>>
>> There is another way to think about the situation.
>>
>> FreeBSD currently caters to only 2 types of users:
>>
>> 1) Dedicated disk users - use BSD schema
>>
>> 2) Slice users - use MBR schema + BSD schema
>>
>> With very little effort, we can make the OS cater to the third kind of
>> users : partition users (use MBR + EBR - no BSD). This makes FreeBSD
>> behaviour same as what other operating systems do - expect the user to
>> use one of the 3 primary partitions for /, and any extra filesystems
>> (/usr or /var or swap) optionally needed to be found in the EBR.

The kernel has supported MBR + EBR since ~1994.  Utility and installer
support is not so good (I used DOS fdisk to created EBRs for testing in
~1994).

> I do not understand why you need to create the BSD label.  Nothing
> in the GEOM framework is forcing you to do that
>
> Is this for a bootable disk or just storage?

Bruce