Date: Sun, 8 Jul 2018 03:50:09 +0530 From: Manish Jain <jude.obscure@yandex.com> To: Polytropon <freebsd@edvax.de>, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Fwd: A request for unnested UFS implementation in MBR Message-ID: <6bbfdaad-6872-1a6b-f176-471e57ac8d0a@yandex.com> In-Reply-To: <20180708001336.4097d20e.freebsd@edvax.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/08/18 03:43, Polytropon wrote:
> On Sun, 8 Jul 2018 03:25:46 +0530, Manish Jain wrote:
>> 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.
>
> You can format a whole slice ("DOS primary partition")
> with the implicit BSD label 'c', which means "the whole
> thing" (here: slice), but that one won't be bootable
> then.
>
> Let's say you have MBR partitions on a disk:
>
> da0 = { [ partition 1 ] [ partition 2 ] }
>
> You then format one as UFS:
>
> # newfs /dev/da0s1
>
> As you see - no BSD partition. It will be assumed implicitely
> as /dev/da0s1c, which is the same as /dev/da0s1, and you can
> now mount this one.
>
> However, you cannot create a bootable partition that way
> as this requires the BSD 'a' label to be present. Here
> bsdlabel comes into use:
>
> da0 = { da0s1 = [ da0s1a da0s1b ... ] [ partition 2 ] }
>
> You'd have to format it as
>
> # newfs /dev/da0s1a
>
> if you wanted to do this manually.
>
>
>
>> If that had not been possible, UFS would not have been
>> possible under GPT.
>
> That is not correct. GPT has a representation of UFS-type
> file systems that MBR simply hasn't. BSD labels can only
> exist within a MBR slice (if MBR is present) or directly
> on the device (if MBR is not present).
>
>
>
>> What I am suggesting is an option for UFS under MBR just as it is under
>> GPT - unnested.
>
> MBR has a restricted set of partition types (slice types).
> Type 165 is a slice that can carry BSD-labeled file systems
> (FreeBSD partitions).
>
>
>
>> 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 ?
>
> Because when BSD came to the PC, the PC was MBR, and MBR
> doesn't allow that. FreeBSD, on the other hand, doesn't _need_
> MBR at all - it's the other ones that need it (like DOS and
> "Windows" and maybe OS/2). This is all only neccessary in
> multi-boot environments. On dedicated disks, there is no
> nesting.
>
> da0 = { da0a, da0b, da0d, da0e, da0f, da0g, da0h }
>
> As you can see, da0c is missing, because it's the same as da0.
> And da0h is the last possible partition as they are limited
> as well.
>
>
>
>> 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 ?
>
> This is because logical volumes inside a DOS extended partitions
> cannot be set to a type that can hold a label / UFS file system,
> especially not a bootable one.
>
> See "man 8 boot" for how booting happens and which exact
> requirements need to be fulfilled.
>
> However, you _can_ do the following. In your mind, create a disk
> with one DOS extended partition, and inside it, create some
> logical volumes. Now newfs them (they will be all 'c' volumes),
> and you can mount them - no problem. However, you cannot get
> one of them to boot as FreeBSD requires an 'a' partition,
> and the active bit must be set for the slice that holds it.
>
> If there are no slices, i. e., no MBR at all, the 'a'
> partition will be found at the start of the disk (where
> normally the 1st slice would reside) and therefore the BIOS
> will transfer boot control through the boot sector loader.
>
>
>
MBR permits 3 primary partitions + 1 EBR slice.
What I meant was one of the three partitions serving as FreeBSD / (UFS,
unnested), and any extra filesystems the user needs reside within the EBR.
In other words, an option for UFS to be just like Ext2 in this respect.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6bbfdaad-6872-1a6b-f176-471e57ac8d0a>