Date: Fri, 20 Apr 2001 01:25:07 +0200 (CEST) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: Sven Huster <sven.huster@mailsurf.com>, Jordan Hubbard <jkh@osd.bsdi.com>, stable@FreeBSD.org, developers@FreeBSD.org Subject: Re: FreeBSD 4.3-RC5 now on ftp.freebsd.org Message-ID: <200104192325.BAA63867@info.iet.unipi.it> In-Reply-To: <200104192001.QAA60154@cs.rpi.edu> from "David E. Cross" at "Apr 19, 2001 04:01:16 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Yes, I would agree with that. I needed to hack the scripts here to mount_mfs
> and cp files back and forth a few times to get everything to work correctly,
> but it does work without panic-ing the system. I can post patches if people
> would find that helpfull.
yes please.
[Jordan, in case we reach consensus on what to do and can test
patches before the release's cut date, do we have permission to
update rc.diskless{1,2} as needed ? These files are not on a critical
part of the system so commits in this area do not pose stability
problems.]
I had a look at Sven's patches, and there is one thing that puzzles
me: when doing the mount_mfs of /etc and restoring files, the
OS has still handles open on the old /etc/rc and /etc/rc.diskless1 .
What happens on subsequent reads from these files (which are long) ?
Do they refer to the old version, the new one, or what ?
The problem did not arise with mount_null because themount was simply
an overlay so (unless the user would override those files as well)
it was clear that the reverence was to the old one.
That said: i read the recent commit logs for nullfs in -current,
ant it seems to be fixed there, unfortunately i have no idea
how hard it is to backport the fixes, some of the diffs are
trivial to understand, some are beyond my (very limited)
understanding of this part of the kernel.
As for stability of the diskless clients:
with the current version of rc.diskless2 in -stable, the only part
which uses mount_null is /etc/ where hopefully nothing gets written
to after the pass in /etc/rc.diskless1 so it should not be
a terrible stability issue.
cheers
luigi
on whether subsequents
> (I am still working on ypserv as well, the problems run very deep in that
> code. Once you know where to look they start popping up all over the place.
> Just as a sample cosider the code:
>
> qhead.cqh_head->dbptr->key = key->data;
>
> Where "key" is a DBT* that was passed back from the berkley db routines...
> now consider a few more database requests come in before that record is accessed again and all of a sudden 'key' isn't pointing at what you originally set it
> to.)
>
> --
> David Cross | email: crossd@cs.rpi.edu
> Lab Director | Rm: 308 Lally Hall
> Rensselaer Polytechnic Institute, | Ph: 518.276.2860
> Department of Computer Science | Fax: 518.276.4033
> I speak only for myself. | WinNT:Linux::Linux:FreeBSD
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104192325.BAA63867>