From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Je4yh-0004aL-Vg for garchives@archives.gentoo.org; Tue, 25 Mar 2008 08:57:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5A8D9E0860; Tue, 25 Mar 2008 08:57:54 +0000 (UTC) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by pigeon.gentoo.org (Postfix) with ESMTP id 16B14E0860 for ; Tue, 25 Mar 2008 08:57:53 +0000 (UTC) Received: by nf-out-0910.google.com with SMTP id f5so1034456nfh.26 for ; Tue, 25 Mar 2008 01:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=G2JpusN7cijWk+tuPEZs0Fop8pLJMVep4V5j/r0V2YA=; b=Uw2lhHUGzd9Hvb6YP1MA458zEQ4Cqoin0P0Xt/rRmeFUp4YdCLdM+JWIH8sRuU161FlCQRIsDbXZ84VBV1QV5SRKz+osb9xYbasdXLqVOP5twhkKsC3Mxicxq7Ssk6YJAtmHLjaUp5S/C4WBelRAo1e4E03dUn4HF27A93FnDiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=g+5JApJyyGtNVnILxownirsbgGhP+FDuRY6rj3MrTIjC44BucD3LiwiUv1AZ2Nf4kGUcNL0pYUo8ggqI+4GaE0Ur12KI9h8PCMFcQrhGanTVZvQ4MDz4WCXghA0Xp3ubCCx65RV2LIP6ocapCq9M5lWNvF8edhzqsbXsKRThgFw= Received: by 10.78.118.5 with SMTP id q5mr18764790huc.62.1206435473273; Tue, 25 Mar 2008 01:57:53 -0700 (PDT) Received: from ?10.0.0.3? ( [41.243.230.74]) by mx.google.com with ESMTPS id 32sm10299779hui.1.2008.03.25.01.57.43 (version=SSLv3 cipher=OTHER); Tue, 25 Mar 2008 01:57:45 -0700 (PDT) From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] defect management block device Date: Tue, 25 Mar 2008 10:56:44 +0200 User-Agent: KMail/1.9.9 References: <20080324143245.GC10053@nibiru.local> <200803242247.00116.alan.mckinnon@gmail.com> <20080325014810.GB2672@nibiru.local> In-Reply-To: <20080325014810.GB2672@nibiru.local> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803251056.44193.alan.mckinnon@gmail.com> X-Archives-Salt: 059f0da4-0431-4d9d-ad90-959fcd987f6e X-Archives-Hash: 02bf03c43b87b27b1a8aec2ccdb2f7ad On Tuesday 25 March 2008, Enrico Weigelt wrote: > * Alan McKinnon wrote: > > If SMART (or something conceptually similar) detects that a drive > > might be failing and be beyond the range of the drive's ability to > > cope, it could raise an event and move the blocks used to another > > disk. > > And it even would get funnier if the drive's relocation table > could be accessed (no idea if this is possible): > The LVM would notice if the drive has relocated an (LBA) block, > move it out of the way (somewhere else in the LV) and then > remove the relocation (never access that LBA block anymore). > This way an slowly dying disk can be used for quite a long time. > Think of boxes with very limited physical access (eg. outoor field > systems) or huge archives w/ non-critical/regeneratable data > (eg. media collections w/ originals available, mirrors, etc). > > The idea of using even old and damaged disks at really low costs > (not counting the power consumption ;-P) is seems quite fascinating > to me :) The tricky part is to figure out where a concept like this fits in the various abstraction layers. You couldn't build it into LVM, as LVM doesn't really know about individual blocks on the disk, it only works with it's own segments. The disk driver itself only really understands it's own IDE/SCSI commands and manipulates the data at the sector level. The file system can work at the block level. So there are at least 3 different allocation unit sizes and no obvious way to write one driver that spans all three. The one idea that keeps coming back to me is a new function in the kernel where a driver for a physical storage device can fire an event if it detects a failing unit, and other drivers can register to receive those events. When it gets one, the high level driver can decide if it should move it's own blocks of data around. In a way, conceptually similar to a GUI event framework. Could be very useful to a niche market - Linux already has 1000s of those :-) - but would require very careful design to not break everything else in the system -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list