I have a related idea. If all of the information in a raidtab can be
derived from a persistent superblock, there should be a tool that allows
generating an actual raidtab file by reading a persistent superblock.
This would be especially useful for dianostic procedures.
Also, is there any downside to using persistent superblocks? This is
still an option in a raidtab, but perhaps it should be defaulted to
enable and the capability of disabling persistent superblocks regarded as
obsolete. I suppose there are cases where one might need to operate
without a persistent superblock for non-magnetic media and such rare
cases, but ordinarily I can see no benefit.
In general, I don't think there is anything wrong with the raidtab method.
We have all sorts of other tools which use configuration files like this,
much as Lilo uses lilo.conf.
-- Mike
On Sun, 2 Apr 2000, Michael T. Babcock wrote:
> This of course suggests that the raidtab file is almost redundant itself and
> could be replaced by command-line options to mkraid. mke2fs certainly
> doesn't require an fstab entry for a filesystem before it can be created or
> dealt with. raidtab should be a place to keep information in case the
> persistant superblock is somehow damaged, imho.
>
> For example:
> mkraid --level=5 --device=/dev/md0 --add=/dev/sda5 --add=/dev/sdb5
> --add=/dev/sdc5 --addspare=/dev/sdd5
> Creating /dev/md0 with:
> /dev/sda5 - disk 0
> /dev/sdb5 - disk 1
> /dev/sdc5 - disk 2
> /dev/sdd5 - spare 0
> .........................Finished.
