From owner-freebsd-current Sat Jul 20 19:27:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA03724 for current-outgoing; Sat, 20 Jul 1996 19:27:47 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA03715 for ; Sat, 20 Jul 1996 19:27:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id TAA16881; Sat, 20 Jul 1996 19:24:47 -0700 (PDT) Message-Id: <199607210224.TAA16881@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Poul-Henning Kamp cc: "Michael L. VanLoon -- HeadCandy.com" , John Dyson , hsu@clinet.fi (Heikki Suonsivu), freebsd-current@freebsd.org Subject: Re: vm work helps In-reply-to: Your message of "Sat, 20 Jul 1996 22:51:17 +0200." <656.837895877@critter.tfs.com> From: David Greenman Reply-To: davidg@root.com Date: Sat, 20 Jul 1996 19:24:47 -0700 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>I have repeatedly hit another problem, CCD seems to screw up if you use >>>shared libraries stored on a striped partition. This would maybe also >>>affect other kinds of access with or without mmap in the loop. >> >>Could you be more specific about how and when ccd screws up in this >>situation? I've been running my entire /usr (shared libraries, bins, >>and all) on ccd for almost a year. Granted, it's NetBSD, but they're >>not *that* different, are they? > >Well, it's absolutely reproducible for me. I stripe a partition over >some disks (2 & 3 have been tried) and run a > cd /usr/src/release > make release >which points over there. >It will usually get all the way through the "make world" in the >chrooted env and then die when the tar-balls are rolled. > >I usually can find some of the shlibs have some number of corrupt/ >wrong pages in them, and sometimes these will persist over reboot. > >This only happens when CCD is used. > >I hope John and David will find time to look over this some time. Just a wild guess: The vop_bmap() code in it is probably broken. We rely heavily on this and if it's broken, the filesystem will be corrupted. NetBSD won't suffer from this because they have much more limited use of the vop_bmap function. Further guessing, I'd guess that the problem is that CCD doesn't limit the forward/behind contiguousness to be within the underlying device's cluster, or something of this nature. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project