Re: amd64: use ffs2 for filesystems created by install
Hi Otto, * Otto Moerbeek wrote: > > Diff below fixes the issue. Snap with it is uploaded. You should be > able to upgrade yor test with it. Did the same series of tests again with your updated snap. Worked as expected! Big thanks for the update and ... cheers Matthias
Re: amd64: use ffs2 for filesystems created by install
> Date: Fri, 21 Feb 2020 11:36:19 +0100 > From: Otto Moerbeek > > On Thu, Feb 20, 2020 at 09:02:32PM +0100, Otto Moerbeek wrote: > > > On Thu, Feb 20, 2020 at 08:20:13PM +0100, Otto Moerbeek wrote: > > > > > On Thu, Feb 20, 2020 at 07:48:25PM +0100, Otto Moerbeek wrote: > > > > > > > On Thu, Feb 20, 2020 at 07:27:55PM +0100, Matthias Schmidt wrote: > > > > > > > > > Hi Otto, > > > > > > > > > > * Otto Moerbeek wrote: > > > > > > Hi, > > > > > > > > > > > > This is amd64 only, it contains some i386 pieces, but those are > > > > > > incomplete. > > > > > > > > > > > > With the diff, install uses ffs2 for the filesystems created during > > > > > > install. All boot loaders (except the floppy one) contain support > > > > > > for > > > > > > loading a kernel from ffs2. > > > > > > > > > > > > To test, create a snapshot (see release(8)) with this diff and use > > > > > > it > > > > > > to install a new system. You could also use the snap at > > > > > > www.drijf.net/openbsd/66. Note that it is unsigned. > > > > > > > > > > > > Note that when you manually create an fs, it still will be ffs1 by > > > > > > default. That is to not disturb other platforms. Use -O2 for ffs2. > > > > > > > > > > > > Please test and provide feedback. One think you should see is that > > > > > > the > > > > > > newfs is much faster and fsck as well, since ffs2 creates inodes > > > > > > lazily and thus has much less inodes to check in the typical case. > > > > > > > > > > I used your provided snap to do a few installations with VMs. The > > > > > following things worked as expected: > > > > > > > > > > * Default install on one disk > > > > > * Install on softraid crypto disk > > > > > * Install on softraid 1 with two disks below > > > > > > > > > > I verified each time with dumpfs that FFS2 was used indeed. > > > > > > > > > > I also checked out a large git repo on the first VM into /home and > > > > > pulled the plug to see how fsck behaves. After reboot, fsck marked / > > > > > as > > > > > clean and then I saw the message that init changed the secure level > > > > > from > > > > > 0 to 1, but nothing more happened. I could type so the system was not > > > > > hanging, however, it was also not checking /home (which I expected). > > > > > I > > > > > waited for 5 minutes, pulled the plug again and the fsck worked as > > > > > normal and the system booted to the login prompt. > > > > > > > > > > I did that multiple times and each time it stopped on the first run. > > > > > After power cycling, everything worked as expected and ... wow, fsck > > > > > on > > > > > FFS2 is indeed fast. > > > > > > > > > > Cheers > > > > > > > > > > Matthias > > > > > > > > Thanks for testing. I am seeing the same problem if I do a vmctl stop > > > > -f of a VM. After that, / gets fscked followed by a hang. Another reset > > > > fixes things. Going to check if this happens with a standard snap. > > > > > > > > -Otto > > > > > > > > > > It odes not happen with an ffs1 root. With ffs2, I'm seeing: > > > > > > WARNING: / was not properly unmounted > > > Automatic boot in progress: starting file system checks. > > > /dev/sd0a (d7c346af87544f00.a): 1806 files, 41159 used, 463552 free > > > (48 frags, 57938 blocks, 0.0% fragmentation) > > > /dev/sd0a (d7c346af87544f00.a): MARKING FILE SYSTEM CLEAN > > > panic: init died (signal 11, exit 0) > > > > > > If I go to single user mode, I can run fsck -p, but then the / fs is > > > gone... > > > that explains why init would die. Investigating further... > > > > > > -Otto > > > > > > > It looks like something is going wrong with the special case for root > > filesystems, a so called hot root. See fsck_ffs/main.c > > > > To be continued. > > > > -Otto > > > > Diff below fixes the issue. Snap with it is uploaded. You should be > able to upgrade yor test with it. That looks like a diff that can be committed now isn't it? Might need an #ifdef FFS2 though for the else case. > Index: ufs/ffs/ffs_vfsops.c > === > RCS file: /cvs/src/sys/ufs/ffs/ffs_vfsops.c,v > retrieving revision 1.182 > diff -u -p -r1.182 ffs_vfsops.c > --- ufs/ffs/ffs_vfsops.c 26 Dec 2019 13:28:49 - 1.182 > +++ ufs/ffs/ffs_vfsops.c 21 Feb 2020 10:34:01 - > @@ -533,8 +533,12 @@ ffs_reload_vnode(struct vnode *vp, void > return (error); > } > > - *ip->i_din1 = *((struct ufs1_dinode *)bp->b_data + > - ino_to_fsbo(fra->fs, ip->i_number)); > + if (fra->fs->fs_magic == FS_UFS1_MAGIC) > + *ip->i_din1 = *((struct ufs1_dinode *)bp->b_data + > + ino_to_fsbo(fra->fs, ip->i_number)); > + else > + *ip->i_din2 = *((struct ufs2_dinode *)bp->b_data + > + ino_to_fsbo(fra->fs, ip->i_number)); > ip->i_effnlink = DIP(ip, nlink); > brelse(bp); > vput(vp); > >
Re: amd64: use ffs2 for filesystems created by install
On Thu, Feb 20, 2020 at 09:02:32PM +0100, Otto Moerbeek wrote: > On Thu, Feb 20, 2020 at 08:20:13PM +0100, Otto Moerbeek wrote: > > > On Thu, Feb 20, 2020 at 07:48:25PM +0100, Otto Moerbeek wrote: > > > > > On Thu, Feb 20, 2020 at 07:27:55PM +0100, Matthias Schmidt wrote: > > > > > > > Hi Otto, > > > > > > > > * Otto Moerbeek wrote: > > > > > Hi, > > > > > > > > > > This is amd64 only, it contains some i386 pieces, but those are > > > > > incomplete. > > > > > > > > > > With the diff, install uses ffs2 for the filesystems created during > > > > > install. All boot loaders (except the floppy one) contain support for > > > > > loading a kernel from ffs2. > > > > > > > > > > To test, create a snapshot (see release(8)) with this diff and use it > > > > > to install a new system. You could also use the snap at > > > > > www.drijf.net/openbsd/66. Note that it is unsigned. > > > > > > > > > > Note that when you manually create an fs, it still will be ffs1 by > > > > > default. That is to not disturb other platforms. Use -O2 for ffs2. > > > > > > > > > > Please test and provide feedback. One think you should see is that the > > > > > newfs is much faster and fsck as well, since ffs2 creates inodes > > > > > lazily and thus has much less inodes to check in the typical case. > > > > > > > > I used your provided snap to do a few installations with VMs. The > > > > following things worked as expected: > > > > > > > > * Default install on one disk > > > > * Install on softraid crypto disk > > > > * Install on softraid 1 with two disks below > > > > > > > > I verified each time with dumpfs that FFS2 was used indeed. > > > > > > > > I also checked out a large git repo on the first VM into /home and > > > > pulled the plug to see how fsck behaves. After reboot, fsck marked / as > > > > clean and then I saw the message that init changed the secure level from > > > > 0 to 1, but nothing more happened. I could type so the system was not > > > > hanging, however, it was also not checking /home (which I expected). I > > > > waited for 5 minutes, pulled the plug again and the fsck worked as > > > > normal and the system booted to the login prompt. > > > > > > > > I did that multiple times and each time it stopped on the first run. > > > > After power cycling, everything worked as expected and ... wow, fsck on > > > > FFS2 is indeed fast. > > > > > > > > Cheers > > > > > > > > Matthias > > > > > > Thanks for testing. I am seeing the same problem if I do a vmctl stop > > > -f of a VM. After that, / gets fscked followed by a hang. Another reset > > > fixes things. Going to check if this happens with a standard snap. > > > > > > -Otto > > > > > > > It odes not happen with an ffs1 root. With ffs2, I'm seeing: > > > > WARNING: / was not properly unmounted > > Automatic boot in progress: starting file system checks. > > /dev/sd0a (d7c346af87544f00.a): 1806 files, 41159 used, 463552 free > > (48 frags, 57938 blocks, 0.0% fragmentation) > > /dev/sd0a (d7c346af87544f00.a): MARKING FILE SYSTEM CLEAN > > panic: init died (signal 11, exit 0) > > > > If I go to single user mode, I can run fsck -p, but then the / fs is gone... > > that explains why init would die. Investigating further... > > > > -Otto > > > > It looks like something is going wrong with the special case for root > filesystems, a so called hot root. See fsck_ffs/main.c > > To be continued. > > -Otto > Diff below fixes the issue. Snap with it is uploaded. You should be able to upgrade yor test with it. -Otto Index: ufs/ffs/ffs_vfsops.c === RCS file: /cvs/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.182 diff -u -p -r1.182 ffs_vfsops.c --- ufs/ffs/ffs_vfsops.c26 Dec 2019 13:28:49 - 1.182 +++ ufs/ffs/ffs_vfsops.c21 Feb 2020 10:34:01 - @@ -533,8 +533,12 @@ ffs_reload_vnode(struct vnode *vp, void return (error); } - *ip->i_din1 = *((struct ufs1_dinode *)bp->b_data + - ino_to_fsbo(fra->fs, ip->i_number)); + if (fra->fs->fs_magic == FS_UFS1_MAGIC) + *ip->i_din1 = *((struct ufs1_dinode *)bp->b_data + + ino_to_fsbo(fra->fs, ip->i_number)); + else + *ip->i_din2 = *((struct ufs2_dinode *)bp->b_data + + ino_to_fsbo(fra->fs, ip->i_number)); ip->i_effnlink = DIP(ip, nlink); brelse(bp); vput(vp);
Re: amd64: use ffs2 for filesystems created by install
On Thu, Feb 20, 2020 at 08:20:13PM +0100, Otto Moerbeek wrote: > On Thu, Feb 20, 2020 at 07:48:25PM +0100, Otto Moerbeek wrote: > > > On Thu, Feb 20, 2020 at 07:27:55PM +0100, Matthias Schmidt wrote: > > > > > Hi Otto, > > > > > > * Otto Moerbeek wrote: > > > > Hi, > > > > > > > > This is amd64 only, it contains some i386 pieces, but those are > > > > incomplete. > > > > > > > > With the diff, install uses ffs2 for the filesystems created during > > > > install. All boot loaders (except the floppy one) contain support for > > > > loading a kernel from ffs2. > > > > > > > > To test, create a snapshot (see release(8)) with this diff and use it > > > > to install a new system. You could also use the snap at > > > > www.drijf.net/openbsd/66. Note that it is unsigned. > > > > > > > > Note that when you manually create an fs, it still will be ffs1 by > > > > default. That is to not disturb other platforms. Use -O2 for ffs2. > > > > > > > > Please test and provide feedback. One think you should see is that the > > > > newfs is much faster and fsck as well, since ffs2 creates inodes > > > > lazily and thus has much less inodes to check in the typical case. > > > > > > I used your provided snap to do a few installations with VMs. The > > > following things worked as expected: > > > > > > * Default install on one disk > > > * Install on softraid crypto disk > > > * Install on softraid 1 with two disks below > > > > > > I verified each time with dumpfs that FFS2 was used indeed. > > > > > > I also checked out a large git repo on the first VM into /home and > > > pulled the plug to see how fsck behaves. After reboot, fsck marked / as > > > clean and then I saw the message that init changed the secure level from > > > 0 to 1, but nothing more happened. I could type so the system was not > > > hanging, however, it was also not checking /home (which I expected). I > > > waited for 5 minutes, pulled the plug again and the fsck worked as > > > normal and the system booted to the login prompt. > > > > > > I did that multiple times and each time it stopped on the first run. > > > After power cycling, everything worked as expected and ... wow, fsck on > > > FFS2 is indeed fast. > > > > > > Cheers > > > > > > Matthias > > > > Thanks for testing. I am seeing the same problem if I do a vmctl stop > > -f of a VM. After that, / gets fscked followed by a hang. Another reset > > fixes things. Going to check if this happens with a standard snap. > > > > -Otto > > > > It odes not happen with an ffs1 root. With ffs2, I'm seeing: > > WARNING: / was not properly unmounted > Automatic boot in progress: starting file system checks. > /dev/sd0a (d7c346af87544f00.a): 1806 files, 41159 used, 463552 free > (48 frags, 57938 blocks, 0.0% fragmentation) > /dev/sd0a (d7c346af87544f00.a): MARKING FILE SYSTEM CLEAN > panic: init died (signal 11, exit 0) > > If I go to single user mode, I can run fsck -p, but then the / fs is gone... > that explains why init would die. Investigating further... > > -Otto > It looks like something is going wrong with the special case for root filesystems, a so called hot root. See fsck_ffs/main.c To be continued. -Otto
Re: amd64: use ffs2 for filesystems created by install
On Thu, Feb 20, 2020 at 07:48:25PM +0100, Otto Moerbeek wrote: > On Thu, Feb 20, 2020 at 07:27:55PM +0100, Matthias Schmidt wrote: > > > Hi Otto, > > > > * Otto Moerbeek wrote: > > > Hi, > > > > > > This is amd64 only, it contains some i386 pieces, but those are > > > incomplete. > > > > > > With the diff, install uses ffs2 for the filesystems created during > > > install. All boot loaders (except the floppy one) contain support for > > > loading a kernel from ffs2. > > > > > > To test, create a snapshot (see release(8)) with this diff and use it > > > to install a new system. You could also use the snap at > > > www.drijf.net/openbsd/66. Note that it is unsigned. > > > > > > Note that when you manually create an fs, it still will be ffs1 by > > > default. That is to not disturb other platforms. Use -O2 for ffs2. > > > > > > Please test and provide feedback. One think you should see is that the > > > newfs is much faster and fsck as well, since ffs2 creates inodes > > > lazily and thus has much less inodes to check in the typical case. > > > > I used your provided snap to do a few installations with VMs. The > > following things worked as expected: > > > > * Default install on one disk > > * Install on softraid crypto disk > > * Install on softraid 1 with two disks below > > > > I verified each time with dumpfs that FFS2 was used indeed. > > > > I also checked out a large git repo on the first VM into /home and > > pulled the plug to see how fsck behaves. After reboot, fsck marked / as > > clean and then I saw the message that init changed the secure level from > > 0 to 1, but nothing more happened. I could type so the system was not > > hanging, however, it was also not checking /home (which I expected). I > > waited for 5 minutes, pulled the plug again and the fsck worked as > > normal and the system booted to the login prompt. > > > > I did that multiple times and each time it stopped on the first run. > > After power cycling, everything worked as expected and ... wow, fsck on > > FFS2 is indeed fast. > > > > Cheers > > > > Matthias > > Thanks for testing. I am seeing the same problem if I do a vmctl stop > -f of a VM. After that, / gets fscked followed by a hang. Another reset > fixes things. Going to check if this happens with a standard snap. > > -Otto > It odes not happen with an ffs1 root. With ffs2, I'm seeing: WARNING: / was not properly unmounted Automatic boot in progress: starting file system checks. /dev/sd0a (d7c346af87544f00.a): 1806 files, 41159 used, 463552 free (48 frags, 57938 blocks, 0.0% fragmentation) /dev/sd0a (d7c346af87544f00.a): MARKING FILE SYSTEM CLEAN panic: init died (signal 11, exit 0) If I go to single user mode, I can run fsck -p, but then the / fs is gone... that explains why init would die. Investigating further... -Otto
Re: amd64: use ffs2 for filesystems created by install
On Thu, Feb 20, 2020 at 07:27:55PM +0100, Matthias Schmidt wrote: > Hi Otto, > > * Otto Moerbeek wrote: > > Hi, > > > > This is amd64 only, it contains some i386 pieces, but those are > > incomplete. > > > > With the diff, install uses ffs2 for the filesystems created during > > install. All boot loaders (except the floppy one) contain support for > > loading a kernel from ffs2. > > > > To test, create a snapshot (see release(8)) with this diff and use it > > to install a new system. You could also use the snap at > > www.drijf.net/openbsd/66. Note that it is unsigned. > > > > Note that when you manually create an fs, it still will be ffs1 by > > default. That is to not disturb other platforms. Use -O2 for ffs2. > > > > Please test and provide feedback. One think you should see is that the > > newfs is much faster and fsck as well, since ffs2 creates inodes > > lazily and thus has much less inodes to check in the typical case. > > I used your provided snap to do a few installations with VMs. The > following things worked as expected: > > * Default install on one disk > * Install on softraid crypto disk > * Install on softraid 1 with two disks below > > I verified each time with dumpfs that FFS2 was used indeed. > > I also checked out a large git repo on the first VM into /home and > pulled the plug to see how fsck behaves. After reboot, fsck marked / as > clean and then I saw the message that init changed the secure level from > 0 to 1, but nothing more happened. I could type so the system was not > hanging, however, it was also not checking /home (which I expected). I > waited for 5 minutes, pulled the plug again and the fsck worked as > normal and the system booted to the login prompt. > > I did that multiple times and each time it stopped on the first run. > After power cycling, everything worked as expected and ... wow, fsck on > FFS2 is indeed fast. > > Cheers > > Matthias Thanks for testing. I am seeing the same problem if I do a vmctl stop -f of a VM. After that, / gets fscked followed by a hang. Another reset fixes things. Going to check if this happens with a standard snap. -Otto
Re: amd64: use ffs2 for filesystems created by install
Hi Otto, * Otto Moerbeek wrote: > Hi, > > This is amd64 only, it contains some i386 pieces, but those are > incomplete. > > With the diff, install uses ffs2 for the filesystems created during > install. All boot loaders (except the floppy one) contain support for > loading a kernel from ffs2. > > To test, create a snapshot (see release(8)) with this diff and use it > to install a new system. You could also use the snap at > www.drijf.net/openbsd/66. Note that it is unsigned. > > Note that when you manually create an fs, it still will be ffs1 by > default. That is to not disturb other platforms. Use -O2 for ffs2. > > Please test and provide feedback. One think you should see is that the > newfs is much faster and fsck as well, since ffs2 creates inodes > lazily and thus has much less inodes to check in the typical case. I used your provided snap to do a few installations with VMs. The following things worked as expected: * Default install on one disk * Install on softraid crypto disk * Install on softraid 1 with two disks below I verified each time with dumpfs that FFS2 was used indeed. I also checked out a large git repo on the first VM into /home and pulled the plug to see how fsck behaves. After reboot, fsck marked / as clean and then I saw the message that init changed the secure level from 0 to 1, but nothing more happened. I could type so the system was not hanging, however, it was also not checking /home (which I expected). I waited for 5 minutes, pulled the plug again and the fsck worked as normal and the system booted to the login prompt. I did that multiple times and each time it stopped on the first run. After power cycling, everything worked as expected and ... wow, fsck on FFS2 is indeed fast. Cheers Matthias
amd64: use ffs2 for filesystems created by install
Hi,
This is amd64 only, it contains some i386 pieces, but those are
incomplete.
With the diff, install uses ffs2 for the filesystems created during
install. All boot loaders (except the floppy one) contain support for
loading a kernel from ffs2.
To test, create a snapshot (see release(8)) with this diff and use it
to install a new system. You could also use the snap at
www.drijf.net/openbsd/66. Note that it is unsigned.
Note that when you manually create an fs, it still will be ffs1 by
default. That is to not disturb other platforms. Use -O2 for ffs2.
Please test and provide feedback. One think you should see is that the
newfs is much faster and fsck as well, since ffs2 creates inodes
lazily and thus has much less inodes to check in the typical case.
-Otto
PS: the snap was built without the new boot version numbers.
Index: distrib/amd64/common/install.md
===
RCS file: /cvs/src/distrib/amd64/common/install.md,v
retrieving revision 1.55
diff -u -p -r1.55 install.md
--- distrib/amd64/common/install.md 28 Jul 2017 18:15:44 - 1.55
+++ distrib/amd64/common/install.md 20 Feb 2020 12:36:11 -
@@ -34,6 +34,8 @@
MDXAPERTURE=2
MDXDM=y
NCPU=$(sysctl -n hw.ncpufound)
+MDFSOPT=-O2
+MDROOTFSOPT=-O2
if dmesg | grep -q 'efifb0 at mainbus0'; then
MDEFI=y
Index: distrib/miniroot/install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1147
diff -u -p -r1.1147 install.sub
--- distrib/miniroot/install.sub2 Feb 2020 20:33:52 - 1.1147
+++ distrib/miniroot/install.sub20 Feb 2020 12:36:11 -
@@ -507,7 +507,7 @@ configure_disk() {
# Use machine-dependent newfs options for the root
# partition if defined.
- _opt=
+ _opt=$MDFSOPT
[[ $_mp == / ]] && _opt=$MDROOTFSOPT
newfs -q $_opt ${_pp##/dev/}
@@ -3328,6 +3328,7 @@ umount -af >/dev/null 2>&1
#
# The following variables can be provided if required:
# MDEFI - set to 'y' on archs that support GPT partitioning
+# MDFSOPT - newfs options for non-root partitions
# MDROOTFSOPT - newfs options for the root partition
# MDSETS - list of files to add to DEFAULT and ALLSETS
# MDSANESETS - list of files to add to SANESETS
Index: sys/arch/amd64/stand/biosboot/biosboot.S
===
RCS file: /cvs/src/sys/arch/amd64/stand/biosboot/biosboot.S,v
retrieving revision 1.7
diff -u -p -r1.7 biosboot.S
--- sys/arch/amd64/stand/biosboot/biosboot.S5 Jul 2011 17:38:54 -
1.7
+++ sys/arch/amd64/stand/biosboot/biosboot.S20 Feb 2020 12:36:32 -
@@ -108,6 +108,9 @@
* While this can be calculated as
* howmany(di_size, fs_bsize) it takes us too
* many code bytes to do it.
+ * blkskew uint8t the skew used to parse di_db[]. this is set to four by
+ * installboot for ffs2 (due to 64-bit blocks) and should
+ * be zero for ffs1.
*
* All of these are patched directly into the code where they are used
* (once only, each), to save space.
@@ -121,7 +124,7 @@
*/
.globl inodeblk, inodedbl, fs_bsize_p, fsbtodb, p_offset, nblocks
- .globl fs_bsize_s, force_chs
+ .globl fs_bsize_s, force_chs, blkskew
.type inodeblk, @function
.type inodedbl, @function
.type fs_bsize_p, @function
@@ -130,6 +133,7 @@
.type p_offset, @function
.type nblocks, @function
.type force_chs, @function
+ .type blkskew, @function
/* Clobbers %ax, maybe more */
@@ -460,6 +464,8 @@ load_blocks:
/* Get the next filesystem block number into %eax */
lodsl /* %eax = *(%si++), make sure 0x66 0xad */
+blkskew = .+2
+ addw$0x90, %si /* adjust %si if needed (for ffs2) */
pushal /* Save all 32-bit registers */
Index: sys/arch/amd64/stand/boot/Makefile
===
RCS file: /cvs/src/sys/arch/amd64/stand/boot/Makefile,v
retrieving revision 1.44
diff -u -p -r1.44 Makefile
--- sys/arch/amd64/stand/boot/Makefile 28 Nov 2019 00:17:10 - 1.44
+++ sys/arch/amd64/stand/boot/Makefile 20 Feb 2020 12:36:32 -
@@ -40,6 +40,9 @@ SRCS+=close.c closeall.c cons.c cread.c
fstat.c lseek.c open.c read.c readdir.c stat.c
SRCS+= elf32.c elf64.c loadfile.c arc4.c
SRCS+= ufs.c
+.if empty(COPTS:M-DFDBOOT)
+SRCS+= ufs2.c
+.endif
.if ${SOFTRAID:L} == "yes"
SRCS+= aes_xts.c bcrypt_pbkdf.c blowfish.c explicit_bzero.c hmac_sha1.c \
pkcs5_pbkdf2.c rijndael.c sha1.c sha2.c softraid.c
Index:
