From owner-freebsd-questions@freebsd.org Sat Jul 7 22:22:24 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 180131031F91 for ; Sat, 7 Jul 2018 22:22:24 +0000 (UTC) (envelope-from jude.obscure@yandex.com) Received: from forward104p.mail.yandex.net (forward104p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9049F8F4DC for ; Sat, 7 Jul 2018 22:22:23 +0000 (UTC) (envelope-from jude.obscure@yandex.com) Received: from mxback8o.mail.yandex.net (mxback8o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::22]) by forward104p.mail.yandex.net (Yandex) with ESMTP id 8EA381820B2; Sun, 8 Jul 2018 01:22:13 +0300 (MSK) Received: from smtp3p.mail.yandex.net (smtp3p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:8]) by mxback8o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id rIc5BE6Wqu-MDKa8Lvx; Sun, 08 Jul 2018 01:22:13 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1531002133; bh=pRWGDXQkx9fdue/MW0KE4Ft7rm5/kR0NTSeMYXTZAKo=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=In/jpRAB+am32Ug/D1hfYC8bJGHNJUIeAva1U6Urk1r6TzEBAdv+vqW5XntWjqm9+ 0yb2aj9/Uv2rjqXqFqhjQFewRyP+JnwYXvVyHfKoAafq5re+UYYSrgL7USwf2fBBEi Bnasz9/eCGflPhAuG5BKLRJ3HaZrse0CdV4m914U= Received: by smtp3p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id pqeoxUZIqV-MBRiu0hc; Sun, 08 Jul 2018 01:22:12 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1531002132; bh=pRWGDXQkx9fdue/MW0KE4Ft7rm5/kR0NTSeMYXTZAKo=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=Xe3xvJXttjfyj15+bEChdYBiSEEIMGD/PC/LRJLg8++tEnZpP55qwYCrKdwjnMUPn 4awIhSFVOWfYPqBHLw+cPkiNS9/5v6v6LTiPArOcBzXd1wsiFJETXw/ZleDcAuJcsG /LeaU+41fKO6Fem3FSmHPCJJv8DUynV12yE/5hyE= Authentication-Results: smtp3p.mail.yandex.net; dkim=pass header.i=@yandex.com Subject: Re: Fwd: A request for unnested UFS implementation in MBR To: Polytropon , FreeBSD Questions References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> <20180707231908.65a2e973.freebsd@edvax.de> <20180708001336.4097d20e.freebsd@edvax.de> From: Manish Jain Message-ID: <6bbfdaad-6872-1a6b-f176-471e57ac8d0a@yandex.com> Date: Sun, 8 Jul 2018 03:50:09 +0530 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180708001336.4097d20e.freebsd@edvax.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2018 22:22:24 -0000 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.