From owner-freebsd-fs@freebsd.org Sun Jul 8 11:49:11 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 19390103D225 for ; Sun, 8 Jul 2018 11:49:11 +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 AB9F870D16 for ; Sun, 8 Jul 2018 11:49:10 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fc8Bf-000FoX-P4; Sun, 08 Jul 2018 12:49:07 +0100 Date: Sun, 8 Jul 2018 12:49:07 +0100 From: Gary Palmer To: Ronald Klop Cc: freebsd-fs@freebsd.org, Manish Jain Subject: Re: A request for unnested UFS implementation in MBR Message-ID: <20180708114907.GA47960@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 11:49:11 -0000 On Sun, Jul 08, 2018 at 11:02:30AM +0200, 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 > > > Interesting. I don't why this is. freebsd-ufs, freebsd-swap, freebsd-zfs, etc, are GPT IDs. freebsd (without any suffix) is a MBR ID. This is covered in the "gpart" man page under each ID Regards, Gary