lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0911271248210.30903-100000@netrider.rowland.org>
Date:	Fri, 27 Nov 2009 12:58:23 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	tmhikaru@...il.com
cc:	Jan Kara <jack@...e.cz>, Boaz Harrosh <bharrosh@...asas.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>,
	SCSI development list <linux-scsi@...r.kernel.org>,
	<linux-ext4@...r.kernel.org>
Subject: Re: Weird I/O errors with USB hard drive not remounting filesystem
 readonly

On Fri, 27 Nov 2009 tmhikaru@...il.com wrote:

> It is important to me to know exactly how the failure path operates. Please
> explain to me what I will see happen. - Not knowing is driving me nuts.

It goes like this.  The computer sends a lot of READ commands to the
drive.  (For all we know the same thing might happen with WRITEs, but
you didn't do any writing in the test data you sent.)  Every now and
then the drive fails to carry out a READ, for no apparent reason.

Normally the computer then retries, and the READ succeeds the second
time.  But of course, success isn't guaranteed.  When the retry does
succeed, no error messages are printed in the log and everything
continues normally.

Occasionally the computer does not retry the READ -- in circumstances
where it doesn't really need the data (optimistic readahead).  When 
this happens, the failed READ does cause an error message to appear.  
The same thing would happen if the attempted retries were to fail.

Whether or not this would result in lost or corrupted data, or
remounted readonly filesystems, depends on the kind of data being read.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ