linux-kernel - Re: XFS: 2.6.26-rc6 link count mismatch for inode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Jun 2008 14:14:41 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Marco Berizzi <pupilla@...mail.com>
Cc:	linux-kernel@...r.kernel.org, xfs@....sgi.com
Subject: Re: XFS: 2.6.26-rc6 link count mismatch for inode

On Wed, Jun 18, 2008 at 06:39:59PM +0200, Marco Berizzi wrote:
> Dave Chinner wrote:
> 
> > On Mon, Jun 16, 2008 at 11:11:31AM +0200, Marco Berizzi wrote:
> > > Hi Folk,
> > >
> > > I was tring to compile firefox 3.0rc3
> > > and while I was erasing a previous
> > > /tmp/mozilla tree, I started a new
> > > tar xjf mozilla-blabla.
> > > After a while linux 2.6.26-rc6 was
> > > unresponsive: I have unplugged the
> > > power cable. No problem at startup,
> > > but:
> >
> > What are your mount options?
> 
> root@...us:/etc# cat mtab
> /dev/sda2 / xfs rw 0 0
> 
> root@...us:/etc# cat fstab
> /dev/sda2        /                xfs         defaults         1   1

[...]

> XFS mounting filesystem sda2
> Ending clean XFS mount for filesystem: sda2
> VFS: Mounted root (xfs filesystem) readonly.
> 
> > I ask because I've
> > seen this sort of directory corruption before when using volatile
> > write caches and yanking the power....
> >
> > i.e. the corruption could have been caused by the way you reset the
> > system, not because of the hang. Do you have any information on what
> > caused the hang?
> 
> The tar xf mozilla-source.tarball was not responding
> nor writing anything on the disk. I did issue also a
> kill -9 'pid of tar xf' but it did not want to die.
> So I think the problem was on the filesystem before
> the incorrect shutdown.

Yeah, it sounds like the I/O subsystem hung somewhere. Without
details I can't say what went wrong. If it happens again doing
this:

# echo w > /proc/sysrq-trigger

To get a dump of all the blocked processes on the console. That
may contain enough info to tell us what the problem is.

> I can retry the test. Let me know if I can do a
> xfs_repair.

Sure, go ahead and fix it up.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/