[ Thursday, January 20, 2000 ] David Holl wrote:
> I was thinking that recovering etc/raidtab would still be easy with
> cat /proc/sys/dev/md/raidtab.md* > /etc/raidtab
Yes, although I avoided this only because the raidtab format might change
one day and there might be a "global" section (akin to lilo.conf) which
wouldn't really "fit" into these individual raidtabs.
This was just being overly pessimistic, though, and the idea is
still a good one :)
The drivers/block/DAC960.c code keeps a CurrentStatusBuffer for
each controller (or md array in this case) with all the vital info.
While it might be easier to just build it on each read call, keeping this
as a buffer with each array both cuts down on rebuilding redundant data
and allows the future addition of a "master/global" raidtab for scripts
that would rather be able to deal with one file and check on all arrays
(grep -i failed, perhaps), something like the /proc/rd/status from
DAC960.c which spans all controllers.
Also, to keep the raidtab outputs as /etc/raidtab-friendly as possible
you might just want to put the current state (active, spare, failed,
rebuild, etc) as a comment before each disk, possibly commenting out
the entire raid-disk entry for failed disks (your call) but still
keeping them in the output.
Again, it's a great idea (if nothing else, its existance will make for
an easy differentiator between old and new RAID as Ingo's acknowledged
that 2.4 may still have 0.90 RAID as a patch) and we can't wait to help
code/test it :)
James
--
Miscellaneous Engineer --- IBM Netfinity Performance Development
