From owner-freebsd-fs@freebsd.org Mon Jul 9 02:44:14 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 DC30910337C6 for ; Mon, 9 Jul 2018 02:44:13 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 34BC57AFB2; Mon, 9 Jul 2018 02:44:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id C90C91A06DE; Mon, 9 Jul 2018 12:44:01 +1000 (AEST) Date: Mon, 9 Jul 2018 12:44:00 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Gary Palmer cc: Manish Jain , freebsd-fs@freebsd.org Subject: Re: A request for unnested UFS implementation in MBR In-Reply-To: <20180708230442.GB47960@in-addr.com> Message-ID: <20180709115446.X1055@besplex.bde.org> References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> <20180708230442.GB47960@in-addr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=I9sVfJog c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=i2cwMrNwGjVwdpcxgCsA:9 a=CjuIK1q_8ugA:10 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: Mon, 09 Jul 2018 02:44:14 -0000 On Mon, 9 Jul 2018, Gary Palmer wrote: > On Mon, Jul 09, 2018 at 03:05:35AM +0530, Manish Jain wrote: >> ... >> 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 ? > > 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 What is all this messing around with gpart? ffs works on any seekable file, and so does newfs. A unpartitioned disk is the easiest case: Script started on Mon Jul 9 11:51:49 2018 ttyv1:root@besplex:/tmp/u5> mdconfig -a -t malloc -s 512k md0 ttyv1:root@besplex:/tmp/u5> gpart bash: gpart: command not found # gpart doesn't exist on my de-geomed systems ttyv1:root@besplex:/tmp/u5> newfs /dev/md0 /dev/md0: 0.5MB (1024 sectors) block size 16384, fragment size 2048 using 1 cylinder groups of 0.50MB, 32 blks, 64 inodes. super-block backups (for fsck -b #) at: 160 ttyv1:root@besplex:/tmp/u5> fsck_ffs /dev/md0 ** /dev/md0 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2 files, 2 used, 189 free (21 frags, 21 blocks, 11.0% fragmentation) ttyv1:root@besplex:/tmp/u5> mdconfig -d -u 0 ttyv1:root@besplex:/tmp/u5> exit Script done on Mon Jul 9 11:52:24 2018 If the device has to be partitioned starting with an MBR, then things get complicated. I avoid using EBRs except for testing them when I implemented them for FreeBSD in ~1994. FreeBSD's fdisk can't create EBRs and is hard enough to use for MBRs. If you want simplicity, then don't partition the disk. This requires some magic for booting. fdisk generates a fake MBR the same as in ~1992 where it was used more before proper MBR partitioning was implemented. Newer BIOSes might have problems with the fake MBR. I partition all disks except floppies and cd/dvd's and virtual (md) ones. Not partitioning worked better with smaller disks. Now with multi-terabyte disks, partitions are more needed. However, with large disks there is more space to get lost in if you have a complicated partitioning scheme. >> 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. The kernel has supported MBR + EBR since ~1994. Utility and installer support is not so good (I used DOS fdisk to created EBRs for testing in ~1994). > 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? Bruce