Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Nov 2002 11:10:07 -0500 (EST)
From:      Robert Watson <rwatson@freebsd.org>
To:        Sean Kelly <smkelly@zombie.org>
Cc:        current@freebsd.org
Subject:   Re: fsck / and remount failure
Message-ID:  <Pine.NEB.3.96L.1021101110653.34689D-100000@fledge.watson.org>
In-Reply-To: <20021027223407.GA942@edgemaster.zombie.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 27 Oct 2002, Sean Kelly wrote:

> On Sun, Oct 27, 2002 at 05:17:44PM -0500, Robert Watson wrote:
> > Are you using UFS1 extended attributes on that box?
> 
> Yes.
> (290) smkelly@edgemaster:~$ grep UFS /usr/src/sys/i386/conf/EDGEMASTER
> options         UFS_DIRHASH
> options         UFS_EXTATTR
> options         UFS_EXTATTR_AUTOSTART
> options         UFS_ACL
> 
> > I suspect there might
> > be a bug involving the open flags passed to extended attribute backing
> > vnodes such that a remount is refused because there are existing vnodes
> > opened writable.  I.e., the extended attribute backing files are opened
> > FREAD|FWRITE, and since the file system is mounted read-only, remount
> > refuses to upgrade to a rw mount until they are closed.  My guess is that,
> > in fact, this should be permitted, or we should re-open the backing files
> > on a remount.  I'd like to get this bug fixed, but it is another reason to
> > recommend UFS2 over UFS1.
> 
> That would make sense. I had never considered the backing files being
> the cause of it. If necessary, I can rebuild my kernel without ACLs and
> EXTATTRs to see if that cures the problem. 

I suspect it will cure the problem, and I suspect the real solution is
that we need to open the backing files with flags based on the mount flags
(read-only or not), and restart EAs on a remount, allowing the files to be
re-opened with the write flag if needed.

> I haven't switched to UFS2 for a few reasons:
> * I don't know what state it is in (can I boot from it on x86?)

This is probably a question for phk -- my understanding is that we're
either there, or we're very close on the boot issue for i386.  I'm using
it in several places on i386 as non-boot, and on sparc64 as the boot file
system pretty successfully.

> * I don't know how stable it is now

It seems to be pretty stable, and if it's not, we'd really like to find
out.  Because it largely relies on existing UFS1 logic, the chances of it
being stable are a lot higher than if it was a "from scratch"
implementation.

> * I don't really want to have to go through the hassle of backing up and
>   restoring all my data right now. Oh what I'd give for a conversion tool.
>   Hello? Partition Magic people? *shakes wallet*

We talked about implementing a conversion tool from UFS1->UFS2, and
decided it would take more resources than we had easily available, and
that the risks associated with a tool would be high.  The backup/restore
solution is a pain, but the one that is most likely to be successful.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021101110653.34689D-100000>