Random truncated files on USB hard disk with timeouts; how to debug?

[Arrigo Marchiori]

Hello Poul-Henning,

On Wed, Oct 19, 2016 at 07:22:18AM +0000, Poul-Henning Kamp wrote:

> --------
> In message <20161019064315.GB93031 at nuvolo>, Arrigo Marchiori writes:
> 
> >> Y-cables are a big warning sign.
> >> 
> >> You can try plugging the "power-only" plug into a high quality 1
> >> ampere USB charger, but that is no guarantee for success.
> >
> >Yes, I also thought so at first.
> >
> >But I also believe that if anything goes wrong at the hardware level,
> >I should get a big warning from the kernel, instead of a funny
> >apparently-truncated file, that returns to be readable at next
> >reboot...?
> 
> Only if the drive finds out something is wrong and tells the kernel.
> 
> If the drive has bad power supply, that may not happen.

Yes, I understand. But, forgive me for insisting: there is an
inconsistency that is _at filesystem level_ and _temporary_, and this
really puzzles me.

If there was an undetected problem when writing, I would expect
garbage to be written instead of the actual data. Or, no data at
all. But the outcome should be that such data should be
_unrecoverable_ afterwards. Instead, the file is found and probably
correct at next reboot! Last one was a Java source file; if it had
errors internally I would have expected the port not to compile.

If there was a problem when reading, should the kernel not detect an
inconsistency in the data? Like a failed checksum? Because I think it
does: read(2) returns zero bytes, not garbage.

It just happened now, that another compilation filed. I cleaned,
repeated and it worked, without need to reboot. So, the ``funny'' file
seems to be deletable.

Please correct me if I am wrong. And thank you for your replies so far!

Best regards,
-- 
rigo

http://rigo.altervista.org