Fwd: A request for unnested UFS implementation in MBR

[Polytropon]

On Sun, 8 Jul 2018 04:52:11 +0530, Manish Jain wrote:
> On 07/08/18 04:44, Polytropon wrote:
> > They don't. With GPT, there is no need for BSD labels anymore.
> 
> All I am saying is exactly the same possibility for MBR.

This is not possible due to the design of MBR. It's some
kind of "lowest common denominator" in the PC world. The
BSDs have agreed on "sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)"
and the use of partitions inside a slice. It's not that
FreeBSD couldn't do without that. It can, but other
systems on the same disk probably can't.



> We can create a UFS implementation, perhaps named ufs, that gets 
> recorded directly in MBR table. Right now the implementation is 
> freebsd::freebsd-ufs.

The partition type freebsd-ufs is designed for GPT, not
for MBR.

You'd basically have to find a sysid (MBR partition type)
or create a new one that FreeBSD understands as an 'a'
labeled BSD partition and agrees to boot from it. But
still there is the crazy construct of 4 "DOS primary
partitions", and if you need more, you have to remove
one to create a "DOS extended partition" and logical
volumes within it. The numbering is inconvenient, too.

That's why GPT exists. So why not use that, instead of
trying to accomodate outdated MBR to perform a task it
is not designed to do?



> If someone could just touch a few things, it improves things for 
> eternity when we do not have bother about the extra layer (BSD).

As I said, GPT helps with that.



> Any 
> extra filesystems the user needs should be found in the EBR, not in the BSD.

That looks too complicated. Always remember that MBR
and the slices come from DOS, an era that's over.

For multi-booting, Grub can be used. It worked on MBR,
and it works on GPT.



> Why should a PC have multiple nesting schemas ? It only pains the user 
> in the future when the need for the extra nest was only in the past 
> (when there presumably was no EBR nest).

GPT solved that problem years ago.

Unsolved problems, however, contain multi-booting and
the trouble with "Windows" in this context, but that's
nothing FreeBSD should primarily care about.




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...