From owner-freebsd-fs@freebsd.org Sun Jul 8 21:37:44 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 1FC9810358DD for ; Sun, 8 Jul 2018 21:37:44 +0000 (UTC) (envelope-from jude.obscure@yandex.com) Received: from forward102o.mail.yandex.net (forward102o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::602]) (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 B595E8D378 for ; Sun, 8 Jul 2018 21:37:43 +0000 (UTC) (envelope-from jude.obscure@yandex.com) Received: from mxback9j.mail.yandex.net (mxback9j.mail.yandex.net [IPv6:2a02:6b8:0:1619::112]) by forward102o.mail.yandex.net (Yandex) with ESMTP id B36455A02F0E; Mon, 9 Jul 2018 00:37:40 +0300 (MSK) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback9j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ckj24MUSy4-beIq8HrD; Mon, 09 Jul 2018 00:37:40 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1531085860; bh=6sdOqb3K3wKbEzjk/Za5KAxItn6b5wycFmEOOYawd0k=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=dqCDNzIDVPGb7yc2P0UbIWjF9fUBgxgElTHfPPdN11rSTgi8hBrVZo1jfYZr0m8Qz oeG95Zh1idm5zmJqK4GJT744nIhSWEBzNhqwWLo9d414SFDUPVtzLb/cBBIPikNSXF EJ24xvluSifU89gn2HUxv0pSwxnD4y1GUn596FEM= Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 0S8IWT29LD-bcGGixLf; Mon, 09 Jul 2018 00:37:39 +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=1531085859; bh=6sdOqb3K3wKbEzjk/Za5KAxItn6b5wycFmEOOYawd0k=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=xz/oetKd7pXHGwvWs+loadeDmTxSFuVCkle+SsxVO2SI9kb/QwJHqD9NIpGdJb6yV fT6Vg3FT4cQ7XuNduUXsfR6Qii+BKzrJvNAUH/83/S9YrTn+YueiASi+tUvhrxYQ6A 3y0hwMNuvN19TyH41hwRfFjx+7Mw+4zCkC57Hogs= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@yandex.com Subject: Re: A request for unnested UFS implementation in MBR To: Ronald Klop , freebsd-fs@freebsd.org References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> From: Manish Jain Message-ID: Date: Mon, 9 Jul 2018 03:05:35 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 21:37:44 -0000 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 ? 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 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. Thanks - particularly so if you see a valid point in my request. Manish Jain