Date: Thu, 13 Dec 2001 08:53:46 -0800 From: "Pirzyk, Jim" <Jim.Pirzyk@disney.com> To: Garance A Drosihn <drosih@rpi.edu>, arch@FreeBSD.ORG, Kirk McKusick <mckusick@FreeBSD.ORG> Cc: Matthew Dillon <dillon@apollo.backplane.com> Subject: Re: Making installkernel behave better with softupdates Message-ID: <iss.4d98.3c18dd19.12cf3.5@mercury.fan.fa.disney.com> In-Reply-To: <p0510100eb83dfb64667b@[128.113.24.47]> References: <Pine.NEB.3.96L.1011201232300.4004I-100000@fledge.watson.org> <200112021023.fB2ANMi91290@apollo.backplane.com> <p0510100eb83dfb64667b@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 12 December 2001 11:06 pm, Garance A Drosihn wrote:
> From the thread on:
> Re: Enabling Softupdates in default install on -CURRENT
>
> At 2:23 AM -0800 12/2/01, Matthew Dillon wrote:
> >Garance Drosihn wrote:
> >:I expect it would be best to have it default 'off' for /, because the
> >:user can get into strange-seeming failures when installing a new kernel.
> >:I do like the idea of it being on for most other filesystems.
> >
> > I agree. / is still a problem - I have softupdates enabled on
> > my 128M / partitions and if I 'make install' a kernel twice in
> > a row the filesystem runs out of space and the second install
> > fails. But that's the only time I've ever managed to run a
> > softupdates filesystem out of space. If we incorporated a couple
> > of 'sync's (like eight of them) at the beginning of a kernel or
> > world install target it would probably be safe enough.
>
> With my recent investigations into the size of /modules increasing in
> stable (discussed in freebsd-stable a few weeks ago), I noticed that the
> install process for modules goes (loosely-speaking) like this:
>
> for each fname in /modules/*
> cp /modules/fname /modules.old/fname
> for each fname in /usr/obj/.../modules/*
> cp /usr/obj/.../modules/fname /modules/fname
The only problem I see with this is the case where you have
modules in /modules that did not come from /usr/obj/.../modules/*
(Like the DRI modules from XFree86).
- JimP
>
> This strikes me as a worst-case scenario for softupdates. Not only
> that, but doesn't seem like the safest way to make a backup of the
> current modules, or to copy new modules in. I changed that to:
>
> rm -rf /modules.old ; sync
> mv /modules /modules.old
> mkdir /modules
> for each fname in /usr/obj/.../modules/*
> cp /usr/obj/.../modules/fname /modules/fname
>
> I am assuming this would be faster, and better for softupdates, because
> you're only destroying one set of files (all in one nice clean 'rm'),
> instead of destroying both sets of files, one file at a time, by
> copying over the file. It also means the backup step is a relatively
> atomic operation (the 'mv'), and that you're starting out /modules with
> a clean slate. It'd probably be even better to remove /modules.old,
> copy new modules into /modules.new, and then do two 'mv's only if all
> of those succeeded.
>
> Anyway, I should have some free time over the next few weeks, and could
> revisit these ideas and probably come up with the even safer strategy (as
> well as the fancier handling for debug-versions of kernel+modules). Is
> this worth doing? Would changes like this make 'installkernel' behave
> better on a softupdates partition?
--
--- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $
__o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org
_'\<,_ Senior Systems Engineer, Walt Disney Feature Animation
(*)/ (*)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?iss.4d98.3c18dd19.12cf3.5>