From owner-freebsd-arch Thu Dec 13 8:54: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id B8FE637B41B; Thu, 13 Dec 2001 08:54:03 -0800 (PST) Received: from Hermes10.corp.disney.com (hermes10.corp.disney.com [153.7.110.102]) by mail.disney.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBDGqSf09166; Thu, 13 Dec 2001 08:52:28 -0800 (PST) Received: from [172.30.50.1] by hermes.corp.disney.com with ESMTP; Thu, 13 Dec 2001 08:53:18 -0800 Received: from plio.fan.fa.disney.com (plio.fan.fa.disney.com [153.7.118.2]) by pecos.fa.disney.com (8.11.3/8.11.3) with ESMTP id fBDGrl312404; Thu, 13 Dec 2001 08:53:53 -0800 (PST) Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by plio.fan.fa.disney.com (8.9.2/8.9.2) with ESMTP id IAA22548; Thu, 13 Dec 2001 08:53:45 -0800 (PST) (envelope-from Jim.Pirzyk@disney.com) Received: from [172.30.5.103] by mercury.fan.fa.disney.com; Thu, 13 Dec 2001 08:53:45 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Pirzyk, Jim" Organization: Walt Disney Feature Animation To: Garance A Drosihn , arch@FreeBSD.ORG, Kirk McKusick Subject: Re: Making installkernel behave better with softupdates Date: Thu, 13 Dec 2001 08:53:46 -0800 X-Mailer: KMail [version 1.3] Cc: Matthew Dillon References: <200112021023.fB2ANMi91290@apollo.backplane.com> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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