Date: Thu, 26 Sep 2013 15:46:47 +0400 From: Lev Serebryakov <lev@FreeBSD.org> To: Kirk McKusick <mckusick@mckusick.com> Cc: freebsd-fs <freebsd-fs@FreeBSD.org>, Jeff Roberson <jroberson@jroberson.net> Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. Message-ID: <1537848823.20130926154647@serebryakov.spb.ru> In-Reply-To: <201309260612.r8Q6C7kj086301@chez.mckusick.com> References: <138452559.20130925233248@serebryakov.spb.ru> <201309260612.r8Q6C7kj086301@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Kirk. You wrote 26 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3.,= 10:12:07: KM> I do not think that we are likely to find out anything useful from KM> looking at your dumpped /. Notably the errors that were produced were KM> because an indirect block had gottened trashed. Looking at the file KM> image is not going to tell us how they got trashed. Usual cases are KM> memory errors, address line errors on the I/O bus, or I/O error in the KM> disk itself. The journal does not know of these errors, so does not KM> look to correct them. Hence the need for a manual fsck. Kirk, I want to bring into focus, that EINVAL writes were seen for / and /var (which leaded to panic and reboot), and fsck after panic failed for /u= sr and /tmp. So, you words "The journal does not know of these errors, so does not look to correct them." is not belong here. Journal was unable to correct errors on FSes which didn't have any problems at moment of panic! And after all, full fsck didn't find any problems with indirect blocks on / and /var later (yesterday). I repeat again: journal problems were seen on filesystems, which didn't have any visible problems at moment of panic. --=20 // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1537848823.20130926154647>