Fwd: A request for unnested UFS implementation in MBR

[Manish Jain]

On 07/08/18 02:49, Polytropon wrote:
> On Sun, 8 Jul 2018 02:20:56 +0530, Manish Jain wrote:
>> I made a request for FreeBSD UFS filesystem to the freebsd-fs list. Just
>> for opinions on this list, I am forwarding that request underneath.
> 
> I'm not subscribed to that list, so I will answer directly.
> 
> 
> 
>> 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).
> 
> The idea to _not_ use a slice is called "dedicated", because
> it's specific to the BSDs and usually cannot be processed
> with Linux, DOS, or "Windows". In thos approach, there is
> no MBR involved.
> 
> 
> 
>> Can it not be considered as an alternative to provide a UFS partition
>> (unnested) under MBR too ?
> 
> This is not possible. MBR _requires_ slices. Keep in mind:
> MBR = Master Boot Record, which is a "DOS invention", and
> what FreeBSD calls a slice is in fact a "DOS primary partition".
> So MBR requires it, as it can only have two kinds of entries:
> "DOS primary partition" and "DOS extended partition", which
> is able to carry "logical volumes insinde an extended partition".
> 
> As an MBR entry _must_ be a slice, the idea of FreeBSD partitions
> (disklabel-style partitions) inside that slice is the only way
> to properly create FreeBSD partitions on a DOS-compatible system.
> 
> Keep in mind: If you don't run "Windows" or Linux, you don't
> need MBR at all. On FreeBSD-only systems, I usually create
> the partitions directly on the device, so instead of ada0s1a
> I have ada0a, and "whole devices", represented with the letter c
> )which equals no partition letter at all) can also be used
> as data disks (boot disks require an a partition), so for
> example instead of ada1s1c, I just hava ada1.
> 
> 
> 
>> 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.
> 
> That is not possible. MBR doesn't support this. Again: A MBR
> entry _must be_ a slice ("DOS primary partition") which can
> have a non-DOS type, which for FreeBSD is "sysid 165 (0xa5),
> (FreeBSD/NetBSD/386BSD)").
> 
> 
> 
>> 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.
> 
> People tend to prefer GPT because it's easier to deal with
> partitions. More than 4 are allowed, and if you need more
> than 4 on MBR, it's going to be complicated and annoying
> (extended partitioning required).
> 
> Boot managers, on the other hand, like boot0, are only used
> on multi-OS systems. This again requires the use of MBR
> because Linux and especially "Windows" can hardly coexist
> with FreeBSD on a system that has no slices at all, for
> the simple reason that "Windows" requires them for its own
> existence.

Hi Poly / others,

Your answer turns my proposition on its heads. I never suggested doing 
away with MBR. I suggested doing away with the BSD schema that nests the 
UFS partition. If that had not been possible, UFS would not have been 
possible under GPT.

What I am suggesting is an option for UFS under MBR just as it is under 
GPT - unnested.

Why is nesting considered a necessity, or even a desirable feature when 
MBR has an EBR slice dedicated to any auxiliary filesystems that might 
be needed ?

The BSD schema could only be justified for times when MBR had no 
subdivisible slice. At least now MBR has that slice, so why not use it 
as such and use UFS just like Ext2 in this regard ?

Tx
MJ