Date: Thu, 11 Feb 1999 13:23:32 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Matthew Jacob <mjacob@feral.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates Message-ID: <Pine.BSF.3.95.990211131520.5561B-100000@current1.whistle.com> In-Reply-To: <Pine.LNX.4.04.9902110650060.13093-100000@feral-gw>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Feb 1999, Matthew Jacob wrote: > > > :As a consequence, FreeBSD lost out for being considered a candidate > > :at NASA/Ames for large mass storage. Shrug...It may or may not be > > :true that softupdates, per se, are stable. In my opinion, FFS as > > :offered by FreeBSD (and NetBSD) have not shown themselves to be > > :adequate to large (>500GB) filesystems. Sad to say, ext2 under > > :linux works better. > > > > Matt, I don't recall seeing anything from you in regards to > > large filesystems. Looking in the archives, I see one report > > on Jan 27th from you relating to softupdates, but you indicate > > that softupdates was not enabled on the volume in question, > > so it seems unlikely that it is related to softupdates specifically. > > I was misremembering. Softupdates wasn't the issue here but there *had* > been some question about whether this was a problem with softupdates *not* > enabled- that was from way earlier- sorry for jumping into the wrong > thread and sorry for also probably letting a less than felicitous tone > enter this email- I think I'm just really irritated that I didn't get mail > back from Luoqi. Luoqi was "out of contact" for a while.. (had a real life plus work) but he's not responsible for softupdates anyway. I am, and I didn't see any unresolved problems from you... There are two open issues with soft updates BTW.. One is that soft updates stresses the disks so hard that the WD driver gets into an infinite loop when in "single-block mode" (I've seen this a couple of times in tests here) (and can reproduce it, even looked at it in ddb but not totally solved it) (work-around is set flags to ide driver to allow multi-block or Ultra-DMA). The second is that under some situations the system can almost deadlock with processes doing large mmaps and stuff. A workaround is known and I'd likeot discuss it with Matt dillon tonight at the freebsd meeting (you be there matt(D)?) julian There was one that happenned while I was out of town for a few days and when I got back there was some email with it that indicated that it had been found to not be a problem with soft-updates so I let it go. > > > > > There have been several reports of dirty-buffer panics which is > > of concern, but I haven't been able to reproduce the panic myself > > yet. > > Really? I found it fairly easy to reproduce in that every time I had a > large filesystem (e.g. > 10GB) and ran some fairly simple tests that > exercise VM and Filesystem interactions (simple code available on request- > NetBSD and FreeBSD fail in interesting and uninteresting ways. Solaris and > Linux pass unless there's an underlying h/w problem). I stopped testing > when I wasn't getting any response on this (see below for why)- but if > somebody is thinking of attacking this problem again I can certainly do > some testing (I may not be able to make test systems directly available > because of some NASA policies but I can probably snag some systems for > myself to run tests with- I have a couple of FreeBSD systems running > NASA/Ames still plus the ones I have at Feral (although Feral's disk > resources are substantially *less* than NASA/Ames!)). > > Here's a couple of private emails that listed problems I was seeing. It > really seems to live down in the realloc blocks code. I wasn't subscribed > to freebsd-hackers back then, so I probably just didn't get this problem > announced to the right group. > > > ++Date: Thu, 10 Dec 1998 09:01:39 -0800 (PST) > ++From: Matthew Jacob <mjacob@feral.com> > ++To: Jordan K. Hubbard <jkh@zippy.cdrom.com> > ++Cc: Mike Smith <mike@smith.net.au>, Justin T. Gibbs <gibbs@plutotech.com>, > ++dg@root.com > ++Subject: More panics... > ++ > ++ > ++I have not been able to arrange either a GDB line for this test system, > ++nor have I gotten access for others to get to it as yet. > ++ > ++However, with a kernel built from sources around that of Monday night or > ++so, the same testing got: > ++ > ++swap_pager: suggest more swap space: 1028 MB > ++panic: ffs_reallocblks: unallocated block 1 > ++ > ++ > ++With a stack of: > ++ ffs_reallocblks > ++ cluster_write > ++ ffs_write > ++ vn_write > ++ write > ++ > ++Is this of interest considering all the recent commits for the ufs code > ++and new fsck etc.? This was with even a 'normal' (1K/8K) but quite large > ++filesystem. And no, I don't have softupdates on- I just have whatever > ++comes out of the box... > > ++Date: Wed, 16 Dec 1998 08:53:49 -0800 (PST) > ++From: Matthew Jacob <mjacob@feral.com> > ++To: Mike Smith <mike@smith.net.au> > ++Cc: Jordan K. Hubbard <jkh@zippy.cdrom.com>, Justin T. Gibbs <gibbs@plutotech.com>, dg@root.com > ++Subject: Re: More panics... > ++ > ++ > ++Neither Luoqi nor Kirk responded. I've had systems panic and crash even > ++with the realloc blocks code turn off (somewhere in the ffs alloc layer). > ++ > ++I have been unsuccessful in getting 'official' remote access to some of > ++the large systems because the person in charge has pointed out that there > ++is no 'code sharing' Space Act agreement with FreeBSD as there is with > ++NetBSD- this is a disappointment. It also was unhelpful that the problem > ++couldn't be addressed because the 250GB dump server now is running > ++NetBSD-current because it stayed up and was more stable than > ++FreeBSD-current. Damn- I'm having bad luck in getting some buyin at NAS > ++(which is suffering from budget problems but still has a hell of a lot of > ++iron to play with). > ++ > ++With a modest amount of h/w involved (e.g. a 2x180Mhz PPro) and one fast > ++disk, this problem seems to be reproducible. I'm not a filesystem guy (if > ++I'm *anything* from having spread myself too thinly)- so I haven't cycles > ++nor intelligence (probably) to nail it. Whom really will own this problem? > ++I'd rank this is as far more serious than NFS issues. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990211131520.5561B-100000>