David Chinner wrote:
> A patch for you to try, Jeremy. I've just started a test run on it...
>
OK, it seems to work. I haven't given it an overnight run, but its run
longer without failing than it did before.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
David Chinner wrote:
A patch for you to try, Jeremy. I've just started a test run on it...
OK, it seems to work. I haven't given it an overnight run, but its run
longer without failing than it did before.
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Sat, May 12, 2007 at 07:56:20AM -0700, Jeremy Fitzhardinge wrote:
> David Chinner wrote:
> > What I don't understand is that on unmount dirty xfs inodes get
> > written out. Clearly this is not happening - either there's a hole
> > in the writeback logic (unlikely - it was unchanged) or we've
Jan Engelhardt wrote:
> On May 12 2007 07:46, Matt Mackall wrote:
>
>>> You should not assume alphabetical order. Filesystems may be free to
>>> reorder things and return them (1) randomly like in a hash (2) by
>>> creation time during readdir().
>>>
>> There is no assumption. Mercurial
On May 12 2007 07:46, Matt Mackall wrote:
>>
>> You should not assume alphabetical order. Filesystems may be free to
>> reorder things and return them (1) randomly like in a hash (2) by
>> creation time during readdir().
>
>There is no assumption. Mercurial explicitly visits files in
On May 12 2007 07:46, Matt Mackall wrote:
You should not assume alphabetical order. Filesystems may be free to
reorder things and return them (1) randomly like in a hash (2) by
creation time during readdir().
There is no assumption. Mercurial explicitly visits files in
alphabetical order
Jan Engelhardt wrote:
On May 12 2007 07:46, Matt Mackall wrote:
You should not assume alphabetical order. Filesystems may be free to
reorder things and return them (1) randomly like in a hash (2) by
creation time during readdir().
There is no assumption. Mercurial explicitly
On Sat, May 12, 2007 at 07:56:20AM -0700, Jeremy Fitzhardinge wrote:
David Chinner wrote:
What I don't understand is that on unmount dirty xfs inodes get
written out. Clearly this is not happening - either there's a hole
in the writeback logic (unlikely - it was unchanged) or we've missed
David Chinner wrote:
> What I don't understand is that on unmount dirty xfs inodes get
> written out. Clearly this is not happening - either there's a hole
> in the writeback logic (unlikely - it was unchanged) or we've missed
> some case where we need to update the filesize and mark the inode
>
On Sat, May 12, 2007 at 01:23:27PM +0200, Jan Engelhardt wrote:
>
> On May 10 2007 14:54, Jeremy Fitzhardinge wrote:
> What CPU architecture is this happening on? Not i686 with PAE by
> any chance?
>
> >>> Yes. Why?
> >>
> >> I have a bug report where NFS files are
On Sat, May 12, 2007 at 01:21:41PM +0200, Jan Engelhardt wrote:
>
> On May 10 2007 10:38, Matt Mackall wrote:
> >>
> >> for i in `seq 20`; do
> >>hg clone -U --pull a b-$i
> >>hg verify b-$i # always OK
> >>umount /home
> >>sleep 5
>
On May 10 2007 14:54, Jeremy Fitzhardinge wrote:
What CPU architecture is this happening on? Not i686 with PAE by
any chance?
>>> Yes. Why?
>>
>> I have a bug report where NFS files are corrupted only with PAE clients.
>> Corruption is at the end of the (newly untarred)
On May 10 2007 10:38, Matt Mackall wrote:
>>
>> 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
>>
On Fri, May 11, 2007 at 07:48:26AM -0700, Jeremy Fitzhardinge wrote:
> David Chinner wrote:
> >> Yes, that does look like a good candidate. Should I try to
> >> before-and-after this change?
> >>
> >
> > Yes please!
> >
>
> OK, definite result. Before
On Fri, May 11, 2007 at 07:48:26AM -0700, Jeremy Fitzhardinge wrote:
David Chinner wrote:
Yes, that does look like a good candidate. Should I try to
before-and-after this change?
Yes please!
OK, definite result. Before ba87ea699ebd9dd577bf055ebc4a98200e337542:
all OK.
On May 10 2007 14:54, Jeremy Fitzhardinge wrote:
What CPU architecture is this happening on? Not i686 with PAE by
any chance?
Yes. Why?
I have a bug report where NFS files are corrupted only with PAE clients.
Corruption is at the end of the (newly untarred) files. Doesn't happen
On May 10 2007 10:38, Matt Mackall wrote:
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
[...]
This test looks
On Sat, May 12, 2007 at 01:21:41PM +0200, Jan Engelhardt wrote:
On May 10 2007 10:38, Matt Mackall wrote:
for i in `seq 20`; do
hg clone -U --pull a b-$i
hg verify b-$i # always OK
umount /home
sleep 5
mount
On Sat, May 12, 2007 at 01:23:27PM +0200, Jan Engelhardt wrote:
On May 10 2007 14:54, Jeremy Fitzhardinge wrote:
What CPU architecture is this happening on? Not i686 with PAE by
any chance?
Yes. Why?
I have a bug report where NFS files are corrupted only with PAE clients.
David Chinner wrote:
What I don't understand is that on unmount dirty xfs inodes get
written out. Clearly this is not happening - either there's a hole
in the writeback logic (unlikely - it was unchanged) or we've missed
some case where we need to update the filesize and mark the inode
dirty.
David Chinner wrote:
>> Yes, that does look like a good candidate. Should I try to
>> before-and-after this change?
>>
>
> Yes please!
>
OK, definite result. Before ba87ea699ebd9dd577bf055ebc4a98200e337542:
all OK. After: truncated files.
I also got a bmap of a particular truncated
David Chinner wrote:
Yes, that does look like a good candidate. Should I try to
before-and-after this change?
Yes please!
OK, definite result. Before ba87ea699ebd9dd577bf055ebc4a98200e337542:
all OK. After: truncated files.
I also got a bmap of a particular truncated file,
On Thu, May 10, 2007 at 04:49:35PM -0700, Jeremy Fitzhardinge wrote:
> David Chinner wrote:
> > Ok, this is important to kow becase we merged a mod around that time
> > that changes the way we handle the updates to the file size i.e. the
> > fix for the NULL-files-on-crash problem:
> >
> >
David Chinner wrote:
> Ok, this is important to kow becase we merged a mod around that time
> that changes the way we handle the updates to the file size i.e. the
> fix for the NULL-files-on-crash problem:
>
>
On Thu, May 10, 2007 at 04:07:30PM -0700, Jeremy Fitzhardinge wrote:
> David Chinner wrote:
> > Just to confirm this isn't a result of a recent change, can you reproduce
> > this on a 2.6.20 or 2.6.21 kernel? (sorry if you've already done this -
> > I've juggling
> > some many things at once it's
On Thu, May 10, 2007 at 05:51:29PM -0400, Chuck Ebbert wrote:
> Jeremy Fitzhardinge wrote:
> > Chuck Ebbert wrote:
> >> What CPU architecture is this happening on? Not i686 with PAE by
> >> any chance?
> >
> > Yes. Why?
>
> I have a bug report where NFS files are corrupted only with PAE
David Chinner wrote:
> Just to confirm this isn't a result of a recent change, can you reproduce
> this on a 2.6.20 or 2.6.21 kernel? (sorry if you've already done this - I've
> juggling
> some many things at once it's easy to forget little things).
It is the result of a recent change. I had
On Thu, May 10, 2007 at 02:54:25PM -0700, Jeremy Fitzhardinge wrote:
> Chuck Ebbert wrote:
> > Jeremy Fitzhardinge wrote:
> >
> >> Chuck Ebbert wrote:
> >>
> >>> What CPU architecture is this happening on? Not i686 with PAE by
> >>> any chance?
> >>>
> >> Yes. Why?
> >>
> >
>
Chuck Ebbert wrote:
> Jeremy Fitzhardinge wrote:
>
>> Chuck Ebbert wrote:
>>
>>> What CPU architecture is this happening on? Not i686 with PAE by
>>> any chance?
>>>
>> Yes. Why?
>>
>
> I have a bug report where NFS files are corrupted only with PAE clients.
> Corruption is at
Jeremy Fitzhardinge wrote:
> Chuck Ebbert wrote:
>> What CPU architecture is this happening on? Not i686 with PAE by
>> any chance?
>
> Yes. Why?
I have a bug report where NFS files are corrupted only with PAE clients.
Corruption is at the end of the (newly untarred) files. Doesn't happen
Jeremy Fitzhardinge wrote:
> I haven't checked
> this comprehensively
I just did. They're all pure truncations.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Chuck Ebbert wrote:
> What CPU architecture is this happening on? Not i686 with PAE by
> any chance?
Yes. Why?
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jeremy Fitzhardinge wrote:
> David Chinner wrote:
>> Seems very unlikely. Have you unmounted and mounted the filesystem
>> (or rebooted or suspended) between the files being seen good and
>> the files being seen bad?
>>
>
> There was definitely a suspend-resume, and maybe a reboot. I'll try
>
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
On Fri, May 11, 2007 at 07:13:48AM +1000, David Chinner wrote:
> 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:
> > >>
> > >>>
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
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
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.
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.
On Fri, May 11, 2007 at 07:13:48AM +1000, David Chinner wrote:
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?
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
Jeremy Fitzhardinge wrote:
David Chinner wrote:
Seems very unlikely. Have you unmounted and mounted the filesystem
(or rebooted or suspended) between the files being seen good and
the files being seen bad?
There was definitely a suspend-resume, and maybe a reboot. I'll try
again later
Chuck Ebbert wrote:
What CPU architecture is this happening on? Not i686 with PAE by
any chance?
Yes. Why?
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jeremy Fitzhardinge wrote:
I haven't checked
this comprehensively
I just did. They're all pure truncations.
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jeremy Fitzhardinge wrote:
Chuck Ebbert wrote:
What CPU architecture is this happening on? Not i686 with PAE by
any chance?
Yes. Why?
I have a bug report where NFS files are corrupted only with PAE clients.
Corruption is at the end of the (newly untarred) files. Doesn't happen
without PAE.
Chuck Ebbert wrote:
Jeremy Fitzhardinge wrote:
Chuck Ebbert wrote:
What CPU architecture is this happening on? Not i686 with PAE by
any chance?
Yes. Why?
I have a bug report where NFS files are corrupted only with PAE clients.
Corruption is at the end of the (newly
On Thu, May 10, 2007 at 02:54:25PM -0700, Jeremy Fitzhardinge wrote:
Chuck Ebbert wrote:
Jeremy Fitzhardinge wrote:
Chuck Ebbert wrote:
What CPU architecture is this happening on? Not i686 with PAE by
any chance?
Yes. Why?
I have a bug report where NFS
David Chinner wrote:
Just to confirm this isn't a result of a recent change, can you reproduce
this on a 2.6.20 or 2.6.21 kernel? (sorry if you've already done this - I've
juggling
some many things at once it's easy to forget little things).
It is the result of a recent change. I had seen
On Thu, May 10, 2007 at 05:51:29PM -0400, Chuck Ebbert wrote:
Jeremy Fitzhardinge wrote:
Chuck Ebbert wrote:
What CPU architecture is this happening on? Not i686 with PAE by
any chance?
Yes. Why?
I have a bug report where NFS files are corrupted only with PAE clients.
Corruption
On Thu, May 10, 2007 at 04:07:30PM -0700, Jeremy Fitzhardinge wrote:
David Chinner wrote:
Just to confirm this isn't a result of a recent change, can you reproduce
this on a 2.6.20 or 2.6.21 kernel? (sorry if you've already done this -
I've juggling
some many things at once it's easy to
David Chinner wrote:
Ok, this is important to kow becase we merged a mod around that time
that changes the way we handle the updates to the file size i.e. the
fix for the NULL-files-on-crash problem:
On Thu, May 10, 2007 at 04:49:35PM -0700, Jeremy Fitzhardinge wrote:
David Chinner wrote:
Ok, this is important to kow becase we merged a mod around that time
that changes the way we handle the updates to the file size i.e. the
fix for the NULL-files-on-crash problem:
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
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?
On Wed, May 09, 2007 at 05:04:36PM -0700, Jeremy Fitzhardinge wrote:
> David Chinner wrote:
> > Seems very unlikely. Have you unmounted and mounted the filesystem
> > (or rebooted or suspended) between the files being seen good and
> > the files being seen bad?
> >
>
> There was definitely a
David Chinner wrote:
> Seems very unlikely. Have you unmounted and mounted the filesystem
> (or rebooted or suspended) between the files being seen good and
> the files being seen bad?
>
There was definitely a suspend-resume, and maybe a reboot. I'll try
again later on.
J
-
To
On Wed, May 09, 2007 at 04:30:22PM -0700, Jeremy Fitzhardinge wrote:
> David Chinner wrote:
> > On Wed, May 09, 2007 at 02:09:50PM -0700, Jeremy Fitzhardinge wrote:
> >
> >> I've had a couple of instances of a linux-2.6 mercurial repo getting
> >> corrupted in some odd way this morning. It
David Chinner wrote:
> On Wed, May 09, 2007 at 02:09:50PM -0700, Jeremy Fitzhardinge wrote:
>
>> 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
On Wed, May 09, 2007 at 02:09:50PM -0700, Jeremy Fitzhardinge wrote:
> 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
Matt Mackall wrote:
>> Which I am, extensively, but not on the repo that got damaged. That's
>> why I was wondering about the nlink issues. If I qpop a bunch of
>> patches after just pushing them, won't it simply truncate the file?
>>
>
> Yep. But it will break links before doing that.
On Wed, May 09, 2007 at 03:17:58PM -0700, Jeremy Fitzhardinge wrote:
> Matt Mackall wrote:
> >> Mercurial uses a strictly append-only model for updating its repo files,
> >> but it looks like maybe an append operation didn't stick.
> >>
> >
> > (Unless you're using the mq extension, which
Matt Mackall wrote:
>> Mercurial uses a strictly append-only model for updating its repo files,
>> but it looks like maybe an append operation didn't stick.
>>
>
> (Unless you're using the mq extension, which regularly truncates
> files. But you're definitely the first person to run into this
On Wed, May 09, 2007 at 02:09:50PM -0700, Jeremy Fitzhardinge wrote:
> 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
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
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
On Wed, May 09, 2007 at 02:09:50PM -0700, Jeremy Fitzhardinge wrote:
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
Matt Mackall wrote:
Mercurial uses a strictly append-only model for updating its repo files,
but it looks like maybe an append operation didn't stick.
(Unless you're using the mq extension, which regularly truncates
files. But you're definitely the first person to run into this sort of
On Wed, May 09, 2007 at 03:17:58PM -0700, Jeremy Fitzhardinge wrote:
Matt Mackall wrote:
Mercurial uses a strictly append-only model for updating its repo files,
but it looks like maybe an append operation didn't stick.
(Unless you're using the mq extension, which regularly
Matt Mackall wrote:
Which I am, extensively, but not on the repo that got damaged. That's
why I was wondering about the nlink issues. If I qpop a bunch of
patches after just pushing them, won't it simply truncate the file?
Yep. But it will break links before doing that. Basically all
On Wed, May 09, 2007 at 02:09:50PM -0700, Jeremy Fitzhardinge wrote:
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
David Chinner wrote:
On Wed, May 09, 2007 at 02:09:50PM -0700, Jeremy Fitzhardinge wrote:
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.
On Wed, May 09, 2007 at 04:30:22PM -0700, Jeremy Fitzhardinge wrote:
David Chinner wrote:
On Wed, May 09, 2007 at 02:09:50PM -0700, Jeremy Fitzhardinge wrote:
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
David Chinner wrote:
Seems very unlikely. Have you unmounted and mounted the filesystem
(or rebooted or suspended) between the files being seen good and
the files being seen bad?
There was definitely a suspend-resume, and maybe a reboot. I'll try
again later on.
J
-
To unsubscribe
On Wed, May 09, 2007 at 05:04:36PM -0700, Jeremy Fitzhardinge wrote:
David Chinner wrote:
Seems very unlikely. Have you unmounted and mounted the filesystem
(or rebooted or suspended) between the files being seen good and
the files being seen bad?
There was definitely a
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?
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
76 matches
Mail list logo
