linux-ext4 - Re: ext4: (2.6.34-rc4): This should not happen!! Data will be lost

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201004171855.36874.bernd.schubert@fastmail.fm>
Date:	Sat, 17 Apr 2010 18:55:36 +0200
From:	Bernd Schubert <bernd.schubert@...tmail.fm>
To:	Andre Noll <maan@...temlinux.org>
Cc:	Andrew Vasquez <andrew.vasquez@...gic.com>,
	Eric Sandeen <sandeen@...hat.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	Linux Driver <Linux-Driver@...gic.com>,
	Thomas Helle <Helle@...bingen.mpg.de>
Subject: Re: ext4: (2.6.34-rc4): This should not happen!!  Data will be lost

On Friday 16 April 2010, Andre Noll wrote:
> On 09:36, Andrew Vasquez wrote:
> > > > 	qla2xxx 0000:06:09.0: scsi(0:0:0): Abort command issued -- 1 fa6a73
> > > > 2002.
> > > >
> > > > I can't explain why the storage did not complete the request in the
> > > > allotted time.
> > >
> > > Ah, that's valuable information, thanks. The underlying Infortrend
> > > Raid System is rather old but worked without any problems for several
> > > years. We recently replaced its 400G disks by new 2T WD disks. Maybe
> > > the new disks have longer response times, could that be the reason? And
> > > is there a way to increase the timeout value?
> >
> > To update the default timeout value (30 seconds) for commands
> > submitted to /dev/sdn to 60 seconds:
> >
> >         $ echo 60 > /sys/block/sdn/device/timeout
> 
> I will re-run the stress test with a 60 seconds timeout value and follow
> up if this did not help.

That will not help if the command is "SYNCHRONIZE_CACHE", as that ignores 
device settings, but uses scsi default timeout (30s), which is far too small 
for SATA based raid units. Scsi maintainers ignored that and a couple of other 
patches I wrote to improve error handling with Infortrend units. Will send the 
patches again soon.
Also, if the abort command succeeds, it the command should be re-queued and 
should not result in an error. I think my patches also would increase 
verbosity to point out what exactly happened (possibly a wrong return code in 
the qla2xxx driver, although that should activate the next step in error 
handling, I need to find some to go through the code...).

Altogether filesystem unrelated. The filesystem just might be the reason for a 
synchronize-cache, e.g. barriers, etc.

Greetings from Tübingen,
Bernd 
--
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