I was thinking that recovering etc/raidtab would still be easy with
cat /proc/sys/dev/md/raidtab.md* > /etc/raidtab
And offering separated raidtab entries for each array may make for easier
script handling. I'm not sure what such a script would want to do but I
imagine the extra flexibility couldn't hurt.
Or instead of .../md/raidtab.md*, why not .../md/md0/raidtab? ie, each
array has a 'directory' with a few files especially geared to ease
scripting. In addition to a raidtab file, there could also be one called
"status" with a format similar to: (4 disk raid5 & a spare)
sda1,A:sdb1,A:sdc1,A:sdd1,A:sde1,S
Here the letters after each drive could indicate
A Active
S Unused Spare
F Failed
It's a pretty dumb format and could use better thought, but perhaps each
raid array having its own directory would interest people?
Anyhow, I'll start looking into md/raidtab files. :)
On Thu, 20 Jan 2000, James Manning wrote:
-[ Thursday, January 20, 2000 ] David Holl wrote:
-> It could be handy if there was another 'file' in /proc/sys/dev/md that
-> could dump an equivalent raidtab of the running arrays. Or perhaps a
-> separate raidtab for each array: raidtab.md0 raidtab.md1, etc... Is this
-> possible? Should I be the one to get gung-ho about it if I want this bad
-> enough? :)
-
-Actually not a bad idea, since after some hackery (like the scsi-for-ide
-raid1 drive-swap from before) you could sync your array and raidtab
-with a simple cp. I'd probably not bother with sep. ones for each array
-simply b/c the "cp /proc/.../raidtab /etc/raidtab" option would go away,
-although if you want to do both that'd certainly be helpful.
-
-The necessary information is already in place in the structs, and printing
-it back out should be largely just be reversing the scanning process.
-
-Have fun, and let us know when we can help fix/test,
-
-James
---
-Miscellaneous Engineer --- IBM Netfinity Performance Development
-
