From owner-freebsd-fs@freebsd.org Sun Jul 8 23:04:47 2018 Return-Path: Delivered-To: freebsd-fs@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 F3C171040CEB for ; Sun, 8 Jul 2018 23:04:46 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 956F6716BC for ; Sun, 8 Jul 2018 23:04:46 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fcIjT-00051R-1c; Mon, 09 Jul 2018 00:04:43 +0100 Date: Mon, 9 Jul 2018 00:04:42 +0100 From: Gary Palmer To: Manish Jain Cc: Ronald Klop , freebsd-fs@freebsd.org Subject: Re: A request for unnested UFS implementation in MBR Message-ID: <20180708230442.GB47960@in-addr.com> References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 23:04:47 -0000 On Mon, Jul 09, 2018 at 03:05:35AM +0530, Manish Jain wrote: > On 07/08/18 14:32, Ronald Klop wrote: > > On Sat, 07 Jul 2018 07:59:55 +0200, Manish Jain > > wrote: > > > >> Hi all, > >> > >> I am a longtime user of FreeBSD, which now serves as my only OS. > >> > >> 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). > >> > >> Can it not be considered as an alternative to provide a UFS partition > >> (unnested) under MBR too ? > >> > >> 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. > >> > >> 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. > >> > >> Thanks for reading this. > >> Manish Jain > > > > Do you mean something like this? Gpart refuses to create a freebsd-ufs > > partition in the MBR part. > > > > # mdconfig -s 512m > > md0 > > # gpart create -s MBR md0 > > md0 created > > # gpart add -t freebsd-ufs -s 256m md0 > > gpart: Invalid argument > > # gpart add -t freebsd-swap -s 256m md0 > > gpart: Invalid argument > > > > But you can create and newfs other types. > > > > # gpart add -t linux-data -s 256M md0 > > md0s1 added > > # newfs /dev/md0s1 > > /dev/md0s1: 256.0MB (524288 sectors) block size 32768, fragment size 4096 > > ????????using 4 cylinder groups of 64.03MB, 2049 blks, 8320 inodes. > > super-block backups (for fsck_ffs -b #) at: > > ??192, 131328, 262464, 393600 > > > > # gpart add -t freebsd md0 > > md0s2 added > > # newfs /dev/md0s2 > > /dev/md0s2: 256.0MB (524272 sectors) block size 32768, fragment size 4096 > > ????????using 4 cylinder groups of 64.00MB, 2048 blks, 8192 inodes. > > super-block backups (for fsck_ffs -b #) at: > > ??192, 131264, 262336, 393408 > > Hi all, > > I will reply to all the answers (which accumulated as I had a very nice > long sleep, thank you) to this thread here. > > This is what I get currently applying gpart to my USB pen drive: > > /root <<: gpart create -s MBR da0 > da0 created > /root <<: gpart add -t linux-data -s 1G da0 > da0s1 added > /root <<: gpart add -t freebsd-ufs -s 1G da0 > gpart: Invalid argument # WHY ? Hi, As I said in my email, freebsd-ufs is a GPT ID. MBR has a very restricted set of what is considered valid - from memory it's a single byte. That means freebsd-swap, freebsd-zfs, freebsd-ufs, etc aren't valid. > It currently is a real bother having to create UFS, with a whole lot of > extra commands: > > /root <<: gpart add -t freebsd -s 1G da0 > da0s2 added > /root <<: gpart create -s BSD da0s2 > da0s2 created > /root <<: gpart add -t freebsd-ufs da0s2 > da0s2a added There is nothing forcing you to create the BSD label # mdconfig -s 512m md0 # gpart create -s MBR md0 md0 created # gpart add -t freebsd md0 md0s1 added # newfs /dev/md0s1 /dev/md0s1: 512.0MB (1048560 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 128.00MB, 4096 blks, 16384 inodes. super-block backups (for fsck_ffs -b #) at: 192, 262336, 524480, 786624 # mount /dev/md0s1 /mnt # > The extra commands mean that when a user wants to quickly put a > partition on a disk of any kind, it is much easier using Ext2. > > If the original command (highlighted with WHY ?) could succeed as such > (or perhaps with a slight alteration: gpart add -t ufs -s 1G da0), UFS > becomes as convenient as Ext2 for general purpose usage. > > There is another way to think about the situation. > > FreeBSD currently caters to only 2 types of users: > > 1) Dedicated disk users - use BSD schema > > 2) Slice users - use MBR schema + BSD schema > > With very little effort, we can make the OS cater to the third kind of > users : partition users (use MBR + EBR - no BSD). This makes FreeBSD > behaviour same as what other operating systems do - expect the user to > use one of the 3 primary partitions for /, and any extra filesystems > (/usr or /var or swap) optionally needed to be found in the EBR. I do not understand why you need to create the BSD label. Nothing in the GEOM framework is forcing you to do that Is this for a bootable disk or just storage? Regards, Gary