linux-kernel - 2.6.21-git10/11: files getting truncated on xfs? or maybe an nlink problem?

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-next>] [day] [month] [year] [list]

Date:	Wed, 09 May 2007 14:09:50 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	David Chinner <dgc@....com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Matt Mackall <mpm@...enic.com>
Subject: 2.6.21-git10/11: files getting truncated on xfs? or maybe an nlink
 problem?

I've had a couple of instances of a linux-2.6 mercurial repo getting
corrupted in some odd way this morning.  It looks like files are being
truncated; not to size 0, but losing something off the end.

This is on an xfs filesystem.  I haven't had any crashes/oops, and I
don't think its the normal files getting filled with 0 problem.  I saw
this before the most recent set of xfs updates, but it happened again
afterwards too.

Mercurial uses a strictly append-only model for updating its repo files,
but it looks like maybe an append operation didn't stick.

I'm repulling a fresh copy of the repo; I'll be able to compare
before/after.  Update: yep, definitely truncated:

$ ls -l .hg-new/store/data/_documentation/pi-futex.txt.i .hg-broken/store/data/_documentation/pi-futex.txt.i
4 -rw-rw-r-- 1 jeremy jeremy 3309 May  9 09:43 .hg-broken/store/data/_documentation/pi-futex.txt.i
4 -rw-rw-r-- 1 jeremy jeremy 3797 May  9 13:38 .hg-new/store/data/_documentation/pi-futex.txt.i

also
  3476 -rw-rw-r--  1 jeremy jeremy   3558208 May  9 13:55 00manifest.i
  3476 -rw-rw-r--  1 jeremy jeremy   3555200 May  9 09:41 00manifest.i~

where 00manifest.i~ is the broken one. The files are identical up to the
truncation point.

The repo passed "hg verify" just after I pulled it, so this corruption
came about after a while.

Hm, the other possibility is that nlinks is being misreported.  When
cloning a repo, mercurial will generally hard-link files where possible,
and then break the link if it sees nlink > 1.  If xfs is mis-reporting
the link count, then this will cause havok.  Is that possible?  Seems
unlikely, but it would also explain the symptoms.  I just did a linking
clone with an older kernel, and the link count is as expected.

xfs_check passes without any output, which I presume is good.

    J
-
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/