> Date: Fri, 21 Feb 2020 11:36:19 +0100 > From: Otto Moerbeek <o...@drijf.net> > > 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 -0000 1.182 > +++ ufs/ffs/ffs_vfsops.c 21 Feb 2020 10:34:01 -0000 > @@ -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); > >
