Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Oct 2016 10:00:05 +0200
From:      Arrigo Marchiori <ardovm@yahoo.it>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        Arrigo Marchiori via freebsd-fs <freebsd-fs@freebsd.org>
Subject:   Re: Random truncated files on USB hard disk with timeouts; how to debug?
Message-ID:  <20161019080005.GD93031@nuvolo>
In-Reply-To: <7924.1476861738@critter.freebsd.dk>
References:  <20161018152715.GC89691@nuvolo> <51997.1476812624@critter.freebsd.dk> <20161019062812.GA93031@nuvolo> <7759.1476858801@critter.freebsd.dk> <20161019064315.GB93031@nuvolo> <7924.1476861738@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello Poul-Henning,

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

> --------
> In message <20161019064315.GB93031@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161019080005.GD93031>