public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] defect management block device
Date: Tue, 25 Mar 2008 10:56:44 +0200	[thread overview]
Message-ID: <200803251056.44193.alan.mckinnon@gmail.com> (raw)
In-Reply-To: <20080325014810.GB2672@nibiru.local>

On Tuesday 25 March 2008, Enrico Weigelt wrote:
> * Alan McKinnon <alan.mckinnon@gmail.com> 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



      reply	other threads:[~2008-03-25  8:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-24 14:32 [gentoo-user] defect management block device Enrico Weigelt
2008-03-24 15:58 ` Alan McKinnon
2008-03-24 18:23   ` Eric Martin
2008-03-24 20:47     ` Alan McKinnon
2008-03-25  1:48       ` Enrico Weigelt
2008-03-25  8:56         ` Alan McKinnon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200803251056.44193.alan.mckinnon@gmail.com \
    --to=alan.mckinnon@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox