Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754538Ab0AYRux (ORCPT ); Mon, 25 Jan 2010 12:50:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754508Ab0AYRuw (ORCPT ); Mon, 25 Jan 2010 12:50:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55178 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753474Ab0AYRuv (ORCPT ); Mon, 25 Jan 2010 12:50:51 -0500 Message-ID: <4B5DD9DB.7070300@redhat.com> Date: Mon, 25 Jan 2010 12:50:19 -0500 From: Ric Wheeler User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc13 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: tytso@mit.edu, Anton Altaparmakov , Nick Piggin , Dave Chinner , Jan Kara , Hidehiro Kawai , linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, Andrew Morton , Andreas Dilger , Satoshi OSHIMA , linux-fsdevel@vger.kernel.org Subject: Re: IO error semantics References: <4B4EB5B9.4020809@hitachi.com> <4B4EDE5C.8040600@hitachi.com> <4B4EEE86.7080807@hitachi.com> <20100114141803.GB3146@quack.suse.cz> <20100118051847.GA8678@laptop> <20100118060518.GA9151@laptop> <20100118122437.GF7264@discord.disaster> <20100118140039.GA13909@laptop> <4B5DB78D.2090408@redhat.com> <20100125174723.GB28459@thunk.org> In-Reply-To: <20100125174723.GB28459@thunk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1477 Lines: 32 On 01/25/2010 12:47 PM, tytso@mit.edu wrote: > On Mon, Jan 25, 2010 at 10:23:57AM -0500, Ric Wheeler wrote: >> >> For permanent write errors, I would expect any modern drive to do a >> sector remapping internally. We should never need to track this kind >> of information for any modern device that I know of (S-ATA, SAS, >> SSD's and raid arrays should all handle this). > > ... and if the device is run out of all of its blocks in its spare > blocks pool, it's probably well past the time to replace said disk. > > BTW, I really liked Dave Chinner's summary of the issues involved; I > ran into Kawai-san last week at Linux.conf.au, and we discussed pretty > much the same thing over lunch. (i.e., that it's a hard problem, and > in some cases we need to retry the writes, such as a transient FC path > problem --- but some kind of write throttling is critical or we could > end up choking the VM due to too many pages getting dirtied and no way > of cleaning them.) > > - Ted Also note that retrying writes (or reads for that matter) often are counter productive. For those of us who have suffered with trying to migrate data off of an old, failing disk onto a new, shiny one, excessive retries can be painful... ric -- 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/