Prev: copy a file while it is actively being written
Next: Mobile Phone Compatibility = Dead End
From: Jerry Peters on 3 Feb 2010 16:24
Grant Edwards <invalid(a)invalid.invalid> wrote:
> On 2010-02-02, Nuno J. Silva <nunojsilva(a)invalid.invalid> wrote:
>> "David W. Hodgins" <dwhodgins(a)nomail.afraid.org> writes:
>>
>>> On Tue, 02 Feb 2010 17:31:45 -0500, Greg Russell <me(a)invalid.com> wrote:
>>>
>>>> ... so apparently the "diff" output was correct. I can't imagine why the
>>>> cp would fail with no stderr.
>>>
>>> Is the dest filesystem full? Check df.
>>
>> In that case, won't cp say something like "No space left of device"?
>
> Yes, in my experience.
>
>>> Is the dest filesystem fat32, which has small file size limits?
>
> Good suggestion.
>

Wouldn't you still get some type of error, though?

Jerry

From: Stuart Barkley on 3 Feb 2010 21:00
On Tue, 2 Feb 2010 at 18:08 -0000, Nuno J. Silva wrote:

> Greg Russell <me(a)invalid.com> writes:
>
> > On Tue, 02 Feb 2010 22:12:28 +0000, Grant Edwards wrote:
> >
> > $ cmp -l ./ssc_1992_highlights.iso /tmp/ssc_1992/dvd.iso
> > 1827673645 207 217
> > 4243191341 263 273
> >
> > ... so apparently the "diff" output was correct. I can't imagine
> > why the cp would fail with no stderr.
>
> It should catch errors it knows about. If anything bad happens in
> memory or in the storage device, it won't be detected.
>
> You might have bad memory modules (which can corrupt data stored on
> them), a bad disk (optical, magnetic, flash, ...), or even a bad
> data cable.

I suggest this is a winner (ignore the other noise). The "cmp -l"
output shows two bytes which are different between the two files.

decimal 1827673645 = 0x6CF0162D (hex) = 015474013055 (octal)
decimal 4243191341 = 0xFCE9F62D (hex) = 037472373055 (octal)

Notice the last 13 bits of both bad bytes are the same (0x162d (hex)).

Notice the same bit in both differing bytes is set (010 (octal)).

Very much looks like a flaky bit in ram. Try copying the disk
another time or two and use "cmp -l" between the different copies.

You might also boot memtest86 and let it run overnight.
--
I've never been lost; I was once bewildered for three days, but never lost!
-- Daniel Boone
From: The Natural Philosopher on 4 Feb 2010 05:30
Stuart Barkley wrote:
> On Tue, 2 Feb 2010 at 18:08 -0000, Nuno J. Silva wrote:
>
>> Greg Russell <me(a)invalid.com> writes:
>>
>>> On Tue, 02 Feb 2010 22:12:28 +0000, Grant Edwards wrote:
>>>
>>> $ cmp -l ./ssc_1992_highlights.iso /tmp/ssc_1992/dvd.iso
>>> 1827673645 207 217
>>> 4243191341 263 273
>>>
>>> ... so apparently the "diff" output was correct. I can't imagine
>>> why the cp would fail with no stderr.
>> It should catch errors it knows about. If anything bad happens in
>> memory or in the storage device, it won't be detected.
>>
>> You might have bad memory modules (which can corrupt data stored on
>> them), a bad disk (optical, magnetic, flash, ...), or even a bad
>> data cable.
>
> I suggest this is a winner (ignore the other noise). The "cmp -l"
> output shows two bytes which are different between the two files.
>
> decimal 1827673645 = 0x6CF0162D (hex) = 015474013055 (octal)
> decimal 4243191341 = 0xFCE9F62D (hex) = 037472373055 (octal)
>
> Notice the last 13 bits of both bad bytes are the same (0x162d (hex)).
>
> Notice the same bit in both differing bytes is set (010 (octal)).
>
> Very much looks like a flaky bit in ram. Try copying the disk
> another time or two and use "cmp -l" between the different copies.
>
> You might also boot memtest86 and let it run overnight.

Not necessarily RAM then.

I've had an effect like this with bad hardware plugged into the bus.

two bytes set to FF, but ONLY when copying from a floppy disk.

Tuns out a video capture card was the culprit. It was so slow that when
a RAM access address was read whose lower bytes corresponded to its I/O
address followed immediately by and I/O request to read the floppy
controller, It was still decoding that address and responded by grabbing
the I/O bus.

IO agree that in a fully cached system, RAM is a more likely culprit if
its the same place every time.



First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: copy a file while it is actively being written
Next: Mobile Phone Compatibility = Dead End