Date: Mon, 19 Jan 2004 09:01:11 -0800 (PST) From: Doug White <dwhite@gumbysoft.com> To: sebastian ssmoller <sebastian.ssmoller@gmx.net> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: panic: handle_written_inodeblock: live inodedep Message-ID: <20040119085655.Q21951@carver.gumbysoft.com> In-Reply-To: <1074355516.7787.10.camel@tyrael.linnet> References: <1074282376.907.3.camel@tyrael.linnet> <20040116154309.W93165@carver.gumbysoft.com> <1074355516.7787.10.camel@tyrael.linnet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Jan 2004, sebastian ssmoller wrote: > > I believe the report was that it happened if you performed a large I/O > > operation just after booting with a dirty filesystem, so it was running > > concurrently with bgfsck. > > this could be a point - when i got that panic i had one before (hardware > compatibility problems with geforce2, via kt 133 and amd) and i booted > with a dirty fs (of course running bgfsck). > in this situation i started portupgrade (ok possible not a good idea :) > ... Looks like I have something to test. If you do this regularly and don't mind waiting, you can disable background fsck via a rc.conf option. > > It might be repeatable with a generic snapshot. > > i am not sure whether i want to "repeat" it with my system - i could > cause data loss, couldnt it ? Potentially, but my theory was to create a junk filessytem on a test machine, dump /usr/ports on it, take a snapshot, then do somethign else nasty to that FS, like copy another /usr/ports tree onto it. Its also possible that its some sort of conflict between the fack doing an update and the I/O touching the same file or something. More experimentation is needed! -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040119085655.Q21951>