A request for unnested UFS implementation in MBR
Manish Jain
jude.obscure at yandex.com
Sun Jul 8 21:37:44 UTC 2018
On 07/08/18 14:32, Ronald Klop wrote:
> On Sat, 07 Jul 2018 07:59:55 +0200, Manish Jain
> <jude.obscure at yandex.com> wrote:
>
>> Hi all,
>>
>> I am a longtime user of FreeBSD, which now serves as my only OS.
>>
>> There is one request I wished to make for FreeBSD filesystems. While
>> UFS implementation under GPT is unnested just as Ext2, the MBR
>> implementation of UFS continues to piggyback on an unnecessary nest
>> (in a BSD slice).
>>
>> Can it not be considered as an alternative to provide a UFS partition
>> (unnested) under MBR too ?
>>
>> Existing users could continue to use the freebsd::freebsd-ufs scheme,
>> while fresh usage could have the alternative of UFS directly recorded
>> in the MBR.
>>
>> I should perhaps note that unlike most users who have shifted to GPT
>> of late, I much prefer MBR because 1) the scheme's design by itself
>> keeps the number of slices/partitions in a disk manageable; and 2) I
>> can use the boot0 manager, my favourite boot manager.
>>
>> Thanks for reading this.
>> Manish Jain
>
> Do you mean something like this? Gpart refuses to create a freebsd-ufs
> partition in the MBR part.
>
> # mdconfig -s 512m
> md0
> # gpart create -s MBR md0
> md0 created
> # gpart add -t freebsd-ufs -s 256m md0
> gpart: Invalid argument
> # gpart add -t freebsd-swap -s 256m md0
> gpart: Invalid argument
>
> But you can create and newfs other types.
>
> # gpart add -t linux-data -s 256M md0
> md0s1 added
> # newfs /dev/md0s1
> /dev/md0s1: 256.0MB (524288 sectors) block size 32768, fragment size 4096
> using 4 cylinder groups of 64.03MB, 2049 blks, 8320 inodes.
> super-block backups (for fsck_ffs -b #) at:
> 192, 131328, 262464, 393600
>
> # gpart add -t freebsd md0
> md0s2 added
> # newfs /dev/md0s2
> /dev/md0s2: 256.0MB (524272 sectors) block size 32768, fragment size 4096
> using 4 cylinder groups of 64.00MB, 2048 blks, 8192 inodes.
> super-block backups (for fsck_ffs -b #) at:
> 192, 131264, 262336, 393408
Hi all,
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 ?
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
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.
Thanks - particularly so if you see a valid point in my request.
Manish Jain
More information about the freebsd-fs
mailing list