Date: Mon, 9 Jul 2018 12:44:00 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Gary Palmer <gpalmer@freebsd.org> Cc: Manish Jain <jude.obscure@yandex.com>, freebsd-fs@freebsd.org Subject: Re: A request for unnested UFS implementation in MBR Message-ID: <20180709115446.X1055@besplex.bde.org> In-Reply-To: <20180708230442.GB47960@in-addr.com> References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> <op.zltsqgb0kndu52@klop.ws> <bfe79340-8027-9427-4cc6-a82c166727b1@yandex.com> <20180708230442.GB47960@in-addr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180709115446.X1055>