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>