On Tuesday 25 March 2008, Enrico Weigelt wrote: > * Alan McKinnon <[EMAIL PROTECTED]> 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 -- [email protected] mailing list
