Re: dump broken with new kernel

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Mon, 06 Dec 2004 23:23:54 +0100
In message <6.2.0.14.2.20041206134829.08ad2d00_at_pozo.com>, Manfred Antar writes:

>This seems to be when the change was made:
>cvs co  -D"December 3, 2004 20:00 UTC" sys  -- dump broken
>
>cvs co  -D"December 3, 2004 18:00 UTC" sys   -- dump works
>
>The suspect files seem to be:
>sys/kern/vfs_mount.c
>$FreeBSD: src/sys/kern/vfs_mount.c,v 1.156 2004/12/03 19:25:44 phk Exp
>
>sys/sys/mount.h
>$FreeBSD: src/sys/sys/mount.h,v 1.180 2004/12/03 19:33:19 phk Exp $
>
>I know phk has been working on the mount stuff.

It seems I've broken snapshots and I think I've found out how/why.

sbin/mount_ufs.c mounts using the filesystem "ufs".

mksnap_ffs uses filesystem name "ffs".

I think the problem is that previously a MNT_UPDATE would not
actually check the filesystem name provided once it got hold 
of the mountpoint[1] and I start out looking for the filesystem
type first.

The problem is compounded by the fact that "ufs" is the wrong name,
the correct name is "ffs"[2].

I tried to make the name "ffs" and make "ufs" an alias for it, but
it blows up all over the place.

So against my better judgement I have just committed code to the
kernel to accept "ffs" as an alias for "ufs" when it comes to
filesystems.  I'm far from sure that is all there is to it, but
it seems to let dumps work for me again.

Poul-Henning

[1] If anybody have a kernel a couple of weeks old, try this:

	mount -o ro /dev/mumble /mnt	# mount ufs/ffs filesytem
	mount_msdos -u -o rw /mnt	# upgrade it...

    and lets us know if it works.  There may be other checks which
    stop it from working.

[2] "ufs" is a more or less generic layer which could be used
by another storage manager.  It does the search directory and
name management. "ffs" is the storage management which cares
about putting files on disk.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Mon Dec 06 2004 - 21:23:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:24 UTC