public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: David Chinner <dgc@sgi.com>
Cc: 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: Thu, 10 May 2007 14:32:23 -0700	[thread overview]
Message-ID: <46438F67.9060503@goop.org> (raw)
In-Reply-To: <20070510211348.GC86004887@sgi.com>

David Chinner wrote:
> 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?
>   

No, that's an error code from zlib:
#define Z_BUF_ERROR    (-5)

I think it means it got a truncated buffer while decompressing.

> 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?
>   

The hg verify checks the integrity of all the files by decompressing
them and making sure their sha1 hashes are correct.  The fact that the
first hg verify passed is a very strong check that the whole repo's
integrity is sound, both in structure and content.  The second failing
hg verify's messages are all related to truncation.  I haven't checked
this comprehensively, but in every instance I've checked the files are
identical up to the truncation point.  All the error messages are
consistent with pure truncation, not content differences or IO errors.

    J

  parent reply	other threads:[~2007-05-10 21:32 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
2007-05-10 21:23                   ` Matt Mackall
2007-05-10 21:32                   ` Jeremy Fitzhardinge [this message]
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=46438F67.9060503@goop.org \
    --to=jeremy@goop.org \
    --cc=dgc@sgi.com \
    --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