Not really a roadmap, more a few tourist attractions that you might
see on the way if you stick around (and if I stick around)...
Comments welcome.
NeilBrown
- Bad block list
The idea here is to maintain and store on each device a list of
blocks that are known to be 'bad'. This effectively allows us to
fail a single block rather than a whole device when we get a media
write error. Of course if updating the bad-block-list gives an
error we then have to fail the device.
We would also record a bad block if we get a read error on a degraded
array. This would e.g. allow recovery for a degraded raid1 where the
sole remaining device has a bad block.
An array could have multiple errors on different devices and just
those stripes would be considered to be "degraded". As long a no
single stripe had too many bad blocks, the data would still be safe.
Naturally as soon as you get one bad block, the array becomes
susceptible to data loss on a single device failure, so it wouldn't
be advisable to run with non-empty badblock lists for an extended
length of time, However it might provide breathing space until
drive replacement can be achieved.
- hot-device-replace
This is probably the most asked for feature of late. It would allow
a device to be 'recovered' while the original was still in service.
So instead of failing out a device and adding a spare, you can add
the spare, build the data onto it, then fail out the device.
This meshes well with the bad block list. When we find a bad block,
we start a hot-replace onto a spare (if one exists). If sleeping
bad blocks are discovered during the hot-replace process, we don't
lose the data unless we find two bad blocks in the same stripe.
And then we just lose data in that stripe.
Recording in the metadata that a hot-replace was happening might be
a little tricky, so it could be that if you reboot in the middle,
you would have to restart from the beginning. Similarly there would
be no 'intent' bitmap involved for this resync.
Each personality would have to implement much of this independently,
effectively providing a mini raid1 implementation. It would be very
minimal without e.g. read balancing or write-behind etc.
There would be no point implementing this in raid1. Just
raid456 and raid10.
It could conceivably make sense for raid0 and linear, but that is
very unlikely to be implemented.
- split-mirror
This is really a function of mdadm rather than md. It is already
quite possible to break a mirror into two separate single-device
arrays. However it is a sufficiently common operation that it is
probably making it very easy to do with mdadm.
I'm thinking something like
mdadm --create /dev/md/new --split /dev/md/old
will create a new raid1 by taking one device off /dev/md/old (which
must be a raid1) and making an array with exactly the right metadata
and size.
- raid5->raid6 conversion.
This is also a fairly commonly asked for feature.
The first step would be to define a raid6 layout where the Q block
was not rotated around the devices but was always on the last
device. Then we could change a raid5 to a singly-degraded raid6
without moving any data.
The next step would be to implement in-place restriping.
This involves
- freezing a section of the array (all IO blocks)
- copying the data out to a safe backup
- copying it back in with the new layout
- updating the metadata to indicate that the restripe has
progressed.
- repeat.
This would probably be quite slow but it would achieve the desired
result.
Once we have in-place restriping we could change chunksize as
well.
- raid5 reduce number of devices.
We can currently restripe a raid5 (or 6) over a larger number of
devices but not over a smaller number of devices. That means you
cannot undo an increase that you didn't want.
It might be nice to allow this to happen at the same time as
increasing --size (if the devices are big enough) to allow the
array to be restriped without changing the available space.
- cluster raid1
Allow a raid1 to be assembled on multiple hosts that share some
drives, so a cluster filesystem (e.g. ocfs2) can be run over it.
It requires co-ordination to handle failure events and
resync/recovery. Most of this would probably be done in userspace.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
