public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: David Chinner <dgc@sgi.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Mackall <mpm@selenic.com>,
	xfs@oss.sgi.com, michal.k.k.piotrowski@gmail.com
Subject: Re: 2.6.21-git10/11: files getting truncated on xfs? or maybe an nlink problem?
Date: Fri, 11 May 2007 07:13:48 +1000	[thread overview]
Message-ID: <20070510211348.GC86004887@sgi.com> (raw)
In-Reply-To: <46433049.4020003@goop.org>

On Thu, May 10, 2007 at 07:46:33AM -0700, Jeremy Fitzhardinge wrote:
> David Chinner wrote:
> > On Wed, May 09, 2007 at 05:54:09PM -0700, Jeremy Fitzhardinge wrote:
> >   
> >> David Chinner wrote:
> >>     
> >>> Suspend-resume, eh?
> >>>
> >>> There's an immediate suspect. Can you test this specifically for us?
> >>> i.e. download a known good file set, do some stuff, suspend, resume,
> >>> then check the files? If it doesn't show up the first time, can
> >>> you do it a few times just to rule it out?
> >>>       
> >> Well, I've been doing suspend-resume with xfs for a while without
> >> problems; the problems seem to be recent and easily repeatable.  Which
> >> just means that it could be a new suspend-resume problem, of course.
> >>     
> >
> > Ok. I'm just trying to find a relatively simple test case for the
> > problem - seeing as you seem to be able to reliably reproduce this
> > we should be able to work out the trigger...
> >   
> 
> OK, I was able to reproduce it reliably with a script with did basically:
> 
>     for i in `seq 20`; do
>     	hg clone -U --pull a b-$i
>     	hg verify b-$i		# always OK
>     	umount /home
>     	sleep 5
>     	mount /home
>     	hg verify b-$i		# often found truncated files
>     done
>       
> 
> No suspend/resumes involved.  The trees are linux kernel ones, so fairly
> large, but small enough to fit entirely in core.  My script also
> captured xfs_bmap before/after output for files which had tended to be
> corrupted in the past, but unfortunately none of them got corrupted in
> these tests.  But I do have all the trees lying around to extract more
> detail for if you like.

Ok, so most of the of the integrity errors are processed by an
error like this:

drivers/scsi/sata_sil24.c index contains -98 extra bytes
unpacking file drivers/scsi/sata_sil24.c 5715cdfceaca: Error -5 while decompressing data

That's an -EIO and not a normal error to report. Are there any
errors in dmesg or syslog corresponding to this?

The errors tend to imply problems decompressing and patching files,
not that truncates are occurring once the files have been patched.
Can you check that what is being pulled from the repository is correct
before it gets uncompressed?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  parent reply	other threads:[~2007-05-10 21:14 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-09 21:09 2.6.21-git10/11: files getting truncated on xfs? or maybe an nlink problem? Jeremy Fitzhardinge
2007-05-09 21:55 ` Matt Mackall
2007-05-09 22:17   ` Jeremy Fitzhardinge
2007-05-09 22:44     ` Matt Mackall
2007-05-09 22:50       ` Jeremy Fitzhardinge
2007-05-09 23:16 ` David Chinner
2007-05-09 23:30   ` Jeremy Fitzhardinge
2007-05-10  0:01     ` David Chinner
2007-05-10  0:04       ` Jeremy Fitzhardinge
2007-05-10  0:49         ` David Chinner
2007-05-10  0:54           ` Jeremy Fitzhardinge
2007-05-10  1:26             ` David Chinner
     [not found]               ` <46433049.4020003@goop.org>
2007-05-10 15:38                 ` Matt Mackall
2007-05-12 11:21                   ` Jan Engelhardt
2007-05-12 12:46                     ` Matt Mackall
2007-05-14 20:16                       ` Jan Engelhardt
2007-05-14 20:27                         ` Jeremy Fitzhardinge
2007-05-10 21:13                 ` David Chinner [this message]
2007-05-10 21:23                   ` Matt Mackall
2007-05-10 21:32                   ` Jeremy Fitzhardinge
2007-05-10 21:49                     ` Jeremy Fitzhardinge
2007-05-10 21:41         ` Chuck Ebbert
2007-05-10 21:46           ` Jeremy Fitzhardinge
2007-05-10 21:51             ` Chuck Ebbert
2007-05-10 21:54               ` Jeremy Fitzhardinge
2007-05-10 22:58                 ` David Chinner
2007-05-10 23:07                   ` Jeremy Fitzhardinge
2007-05-10 23:27                     ` David Chinner
2007-05-10 23:49                       ` Jeremy Fitzhardinge
2007-05-11  0:32                         ` David Chinner
2007-05-11 14:48                           ` Jeremy Fitzhardinge
2007-05-12  7:56                             ` David Chinner
2007-05-12 11:23                 ` Jan Engelhardt
2007-05-12 13:51                   ` David Chinner
2007-05-12 14:56                     ` Jeremy Fitzhardinge
2007-05-15  0:14                       ` David Chinner
2007-05-15 19:24                     ` Jeremy Fitzhardinge
2007-05-10 23:07               ` David Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070510211348.GC86004887@sgi.com \
    --to=dgc@sgi.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.k.k.piotrowski@gmail.com \
    --cc=mpm@selenic.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox