Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754656AbZIANHP (ORCPT ); Tue, 1 Sep 2009 09:07:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754592AbZIANHO (ORCPT ); Tue, 1 Sep 2009 09:07:14 -0400 Received: from tanas.ca ([206.248.136.31]:39537 "EHLO tanas.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754430AbZIANHN (ORCPT ); Tue, 1 Sep 2009 09:07:13 -0400 MIME-Version: 1.0 Date: Tue, 01 Sep 2009 09:07:11 -0400 From: Andrei Tanas To: Mark Lord Cc: Mark Lord , Tejun Heo , Ric Wheeler , NeilBrown , , IDE/ATA development list , , Jeff Garzik Subject: Re: MD/RAID time out writing superblock In-Reply-To: <4A9C60A1.50303@rtr.ca> References: <004e01ca25e4$c11a54e0$434efea0$@ca> <9cfb6af689a7010df166fdebb1ef516b.squirrel@neil.brown.name> <4A948A82.4080901@redhat.com> <4A94905F.7050705@redhat.com> <005101ca25f4$09006830$1b013890$@ca> <4A94A0E6.4020401@redhat.com> <005401ca25ff$9ac91cc0$d05b5640$@ca> <4A950FA6.4020408@redhat.com> <92cb16daad8278b0aa98125b9e1d057a@localhost> <4A95573A.6090404@redhat.com> <1571f45804875514762f60c0097171e6@localhost> <4A970154.2020507@redhat.com> <4A9B8583.9050601@kernel.org> <4A9BC033.9000909@pobox.com> <4A9C60A1.50303@rtr.ca> Message-ID: <640f6103c45b6cba6f84f887bde227e4@localhost> User-Agent: RoundCube Webmail/0.2.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1690 Lines: 40 >>>> The drive might take a longer time like this when doing error handling >>>> (sector remapping, etc), but then I would expect to see your remapped >>>> sector count grow. >>> >>> Yes, this is a possibility and according to the spec, libata EH should >>> be retrying flushes a few times before giving up but I'm not sure >>> whether keeping retrying for several minutes is a good idea either. >>> Is it? >> .. >> >> Libata will retry only when the FLUSH returns an error, >> and the next FLUSH will continue after the point where >> the first attempt failed. >> >> But if the drive can still auto-relocate sectors, then the >> first FLUSH won't actually fail.. it will simply take longer >> than normal. >> >> A couple of those, and we're into the tens of seconds range >> for time. >> >> Still, it would be good to actually produce an error like that >> to examine under controlled circumstances. >> >> Hmm.. I had a drive here that gave symptoms like that. >> Eventually, I discovered that drive had run out of relocatable >> sectors, too. Mmm.. I'll see if I can get it back (loaned it out) >> and perhaps we can recreate this specific scenario on it.. > .. > > I checked today, and that drive is no longer available. Mine errored out again with exactly the same symptoms, this time after only few days and with the "tunable" set to 2 sec. I got a warranty replacement but haven't shipped this one yet. Let me know if you want it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/