Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 8 Jul 2018 01:35:23 +0100
From:      RW <rwmaillists@googlemail.com>
To:        freebsd-questions@freebsd.org
Subject:   Re: A request for unnested UFS implementation in MBR
Message-ID:  <20180708013523.3f52a997@gumby.homeunix.com>
In-Reply-To: <dbf75cb9-6aa4-a609-97cc-55bd5762e593@yandex.com>
References:  <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> <f57a5540-9736-53bf-5312-166a1b2e23b0@yandex.com> <20180707231908.65a2e973.freebsd@edvax.de> <a09d56e5-38c7-bc52-dc92-49d5956e152d@yandex.com> <20180708001336.4097d20e.freebsd@edvax.de> <6bbfdaad-6872-1a6b-f176-471e57ac8d0a@yandex.com> <20180708004645.5a39c930.freebsd@edvax.de> <939bdcac-d9c3-2863-0e83-e1e87b61ded8@yandex.com> <20180708011444.82511c6a.freebsd@edvax.de> <dbf75cb9-6aa4-a609-97cc-55bd5762e593@yandex.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 
> We can create a UFS implementation, perhaps named ufs, that gets 
> recorded directly in MBR table. Right now the implementation is 
> freebsd::freebsd-ufs.
> 
> If someone could just touch a few things, it improves things for 
> eternity when we do not have bother about the extra layer (BSD). Any 
> extra filesystems the user needs should be found in the EBR, not in
> the BSD.
> 
> 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).

I think it did exist, but BSD avoided the mistake made by Linux in
adopting the EBR kludge.

If you need multiple OSs instances on a drive, it's self-evidently
better to label their partitions  hierarchically rather then number
them in a flat space.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180708013523.3f52a997>