From owner-freebsd-questions@freebsd.org Sat Jul 7 22:08:00 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 A7A801030C06 for ; Sat, 7 Jul 2018 22:08:00 +0000 (UTC) (envelope-from jude.obscure@yandex.com) Received: from forward100p.mail.yandex.net (forward100p.mail.yandex.net [77.88.28.100]) (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 19FB08EBFF for ; Sat, 7 Jul 2018 22:08:00 +0000 (UTC) (envelope-from jude.obscure@yandex.com) Received: from mxback1o.mail.yandex.net (mxback1o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1b]) by forward100p.mail.yandex.net (Yandex) with ESMTP id 7A5E05102726 for ; Sun, 8 Jul 2018 01:07:57 +0300 (MSK) Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [2a02:6b8:0:1a2d::26]) by mxback1o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id qzHSvkVDLK-7vFq95F8; Sun, 08 Jul 2018 01:07:57 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1531001277; bh=+2OPgTxVGEK2p/AM/+Z/2X/UC71//QgseRAkTVLpMLE=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=g/Lftg9wTwfTJVxHMS9A/K1e32/PgwG3oubOaBCKpaINOxksQeC2dUgAdsAOnM1Zo gWtdHJklci9yYk2FKeY21ueUIfgXYvtkwli0VdL9oEndXwt70BJ7radXns3SogM/m2 hcJtqZ2B0cgfNLsE0dEGG7SeYm1brU9c6HBnNI5A= Received: by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id pKMLAWVAN8-7tUOiiE3; Sun, 08 Jul 2018 01:07:56 +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=1531001276; bh=+2OPgTxVGEK2p/AM/+Z/2X/UC71//QgseRAkTVLpMLE=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=G0UjOkTic08I5nOgNAa0rjRr8+ujzLp36cbwvHVABgOpI6wb5Td/t+qo4qSM9qfxg wwdynSGvTWvY/uHFX7DRtAfYRePyVEm976l5Zd2PJ4SZR0Q/0XTt4gQnHgNvMwNPOU TH/1untN41JGmKxCrQqvIc0TfXJNdX9SsWf+fWPA= Authentication-Results: smtp2o.mail.yandex.net; dkim=pass header.i=@yandex.com Subject: Re: Fwd: A request for unnested UFS implementation in MBR To: FreeBSD Questions References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> <20180707231908.65a2e973.freebsd@edvax.de> From: Manish Jain Message-ID: <80a0caea-b0fa-73b4-a679-4bda773edeb1@yandex.com> Date: Sun, 8 Jul 2018 03:35:53 +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: <20180707231908.65a2e973.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:08:01 -0000 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