Date: Thu, 14 Feb 2008 14:09:50 -0600 From: Aaron Hurt <ahurt@goflexitllc.com> To: freebsd-fs@freebsd.org Subject: Re: UFS2 corruption (RELENG_7, amd64) Message-ID: <47B4A00E.1050105@goflexitllc.com> In-Reply-To: <200802141958.m1EJwCoZ078516@lurza.secnetix.de> References: <200802141958.m1EJwCoZ078516@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Have you checked to make sure that there are no physical problems with any of the disks in the array...possibly checked for SMART errors on the drives in the array? Aaron Hurt Managing Partner Flex I.T., LLC 611 Commerce Street Suite 3117 Nashville, TN 37203 Phone: 615.438.7101 E-mail: aaron@goflexitllc.com Oliver Fromme wrote: > Hi, > > We have a problem with a large file system (1.5 TB). > This is a UFS2 that was newfs'ed on FreeBSD/amd64 > RELENG_7 from December 17. > > It was formatted with bsize 64K and fsize 8K because of > performance reasons. Especially fsck is significantly > faster with these settings. There's no disklabel; > the whole raw disk is used. > > Also, the inode density was reduced to one inode per > 256 KB, so there are 5.7 million inodes available, > of which 33,000 are actually in use currently. > The file system contains a busy news spool area. > It is mounted with soft-updates and noatime. > > After while of usage, some corruption seems to occur, > and df(1) output becomes very strange, see below. > This happened several times already. > > ================== snip ================== > > Filesystem 1K-blocks Used Avail Capacity > /dev/da45 1463107704 -1202122007974910440 1202122009320969528 -89306778483% > > # umount /dev/da45 > # fsck -y /dev/da45 > ** /dev/da45 > ** Last Mounted on [...] > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > UNALLOCATED I=2107428 OWNER=2283830233 MODE=0 > SIZE=0 MTIME=Feb 5 08:43 2008 > NAME=/D.0131ae2e/B.0786 > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > REMOVE? yes > > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? yes > > SUMMARY INFORMATION BAD > SALVAGE? yes > > BLK(S) MISSING IN BIT MAPS > SALVAGE? yes > > 24667 files, 116050264 used, 66838199 free (5135 frags, 8354133 blocks, 0.0% fragmentation) > > ***** FILE SYSTEM WAS MODIFIED ***** > > ================== snip ================== > > After a while, the same thing happens again. > > In dmesg I see the following messages, but I have no > idea if they are related to the above problem: > > bad block 724405012343388976, ino 759812 > pid 48 (softdepflush), uid 0 inumber 759812 on /news2/spool/news/22: bad block > bad block -4916881576150019921, ino 759812 > pid 48 (softdepflush), uid 0 inumber 759812 on /news2/spool/news/22: bad block > bad block -131736542334903744, ino 759812 > pid 48 (softdepflush), uid 0 inumber 759812 on /news2/spool/news/22: bad block > bad block -6421737673234919641, ino 759812 > pid 48 (softdepflush), uid 0 inumber 759812 on /news2/spool/news/22: bad block > handle_workitem_freeblocks: block count > > I do not see any SCSI error messages, so I don't > think it is a hardware problem. These are the > related boot messages: > > mpt0: <LSILogic SAS/SATA Adapter> > da49 at mpt0 bus 0 target 10 lun 4 > da49: <IFT S16S-G1030 361F> Fixed Direct Access SCSI-4 device > da49: 300.000MB/s transfers > da49: Command Queueing Enabled > da49: 1430288MB (2929229824 512 byte sectors: 255H 63S/T 182336C) > > Did anyone encounter similar problems? Could it be > caused by the nonstandard bsize/fsize settings? > Are there any known problems, especially on amd64? > > Any hint or advice is very much appreciated! > > Best regards > Oliver > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B4A00E.1050105>