Raid, reiserfs, and FAI

[Devlin]

I've tried to extend FAI to include RAID, working from FAI 2.3.1.  
Following
is a history of my attempt.  I'm not quite sure which is the best way to 
go from
where I am.  I've got some possibilities laid out below, too.

Eric Mumpower suggested writing a hook a while ago on the list, using a 
general
algorithm:
         1) Parse a configuration file
         2) Call setup_harddisks
         3) Create a raidtab file
         4) Execute mkraid
         5) Create an fstab file
         6) Create a $DISKVAR file

I started writing a script to follow this algorithm, called
hooks/partition.RAID .  I decided to describe each partition in the FAI
disk_config/ file, with RAID paritions described in the entries for 
multiple
disks, leaving only one partition listed with the mount point.  I found 
three
problems while implementing, two releated to the functioning of
setup_harddisks, and the other one with the algorithm.
         1) In step 3, the hook does not have lists of partitions for 
each RAID
            device.  setup_harddisks assigns partition numbers 
arbitrarily.  A
            raidtab file needs a list of these partitions to be made into 
a RAID
            device.
         2) setup_harddisks creates a proper fstab.  Mirroring that 
functionality
            makes an extra, unnecessary point of maintenance.  Modifying 
the
            generated fstab circumvents that mirroring.  To modify it, 
the hook
            needs the same list of partitions for each RAID device.
         3) Formatting a set of partitions, and then calling mkraid on 
them
            creates a malfunctional RAID device.

To solve the first two problems, I decided to use ext2 labels.  I 
modified the
hook's configuration to identify the RAID devices these labels.  I 
modified
setup_harddisks to add labels while it formats (and mount2dir to 
understand
an fstab with labels).  Then I added a step after step 2 to read the disk
labels out of /proc/filesystems .  Last, I modified steps 3 and 5 to use 
that
list.  The new algorithm ends up:
         1) Parse a configuration file
         2) Call setup_harddisks
         3) Read labels
         4) Create a raidtab file
         5) Execute mkraid
         6) Modify fstab file
         7) Modify $DISKVAR file

So, I was left with the third problem.  FAI would automatically generate
malfunctional RAID devices.  To fix this, mkraid needs to run after the 
list of
partition numbers is generated, and before the partitions are formatted.
Since those two steps are both in setup_harddisks, I decided to further 
modify
that script.  It follows this general algorithm:
         1) Read harddisk descriptions
         2) Parse configuration files in disk_config/
         3) Build partition tables
         4) Partition harddisks
         5) Format partitions
         6) Create an fstab file
         7) Create a $DISKVAR file
Also, the fix needed to integrate with a normal, non-RAID FAI 
installation.
Thus it could be easily accepted into the distribution, and future 
releases
would work with or without partition.RAID .

So I decided to add two options to setup_harddisks: one to skip 
partitioning,
and the other to skip formatting and writing the configurations.  With 
those,
the hook algorithm would become:
         1) Parse a configuration file
         2) Call setup_harddisks, skipping formatting and writing
         3) Read labels
         4) Create a raidtab file
         5) Execute mkraid
         6) Call setup_harddisks, skipping partitioning
         7) Modify fstab file
         8) Modify $DISKVAR file
But this doesn't work, with just the addition of skip options.  Skipping
formatting and writing works, but skipping partitioning does not.  
Formatting
and writing relies on the partitioning step.

This is the present state of my attempt.  I can think of a few solutions:
         1) We can make the partitioning step write its configuration to
            a file on the disk.  This is a kludge; it would take a small 
effort,
            and there would be no reason to maintain it because it's not
            extensible.
         2) We can restructure setup_harddisks, to have a more granular 
set of
            steps, and then make options to skip steps.  This is 
extensible, and I
            believe it improves the code.  It changes the codebase, so 
that any
            other developers' patches will need to be rewritten.  The new 
algorithm
            that matches the function of the present one might follow this
            structure:
                 1) Read configuration
                 2) Make disk devices (e.g., mknod)
                 3) Set disk devices up (e.g., hdparm)
                 4) Make partition devices (e.g., sfdisk)
                 5) Set partition devices up (e.g., mkraid && raidstart)
                 6) Make filesystems (e.g., mkfs)
                 7) Set filesystems up (e.g., tune2fs)
                 8) Write configuration (i.e., fstab, raidtab, $DISKVAR)
         3) We can also rewrite portions of setup_harddisks to support 
RAID
            devices in disk_config/ files.  This will be kinda hard, but 
cool.
            Though it is not as ideally elegant, it is more practically 
elegant;
            an FAI user can simply configure FAI to set up RAID devices, 
and it
            will work.
         4) We can fragment setup_harddisks into seperate FAI tasks.  I 
don't
            really see a solid benefit to this one.

I don't know which to do.  My favorite is solution 2.  Generally, that 
can move
towards having tasks divided into more granular subtasks.  That might 
help making
extensions to FAI, or maybe it'll just be unnecessary complication.

On Friday, July 12, 2002, at 04:53 PM, Paul Lussier wrote:

> In a message dated: Fri, 12 Jul 2002 14:00:12 EDT
> James Russell said:
>
>> Paul,
>>
>> Not sure if this would help, but maybe running the mkraid/mkreiserfs
>> commands under chroot. If it works, post the fix to the list.
>
> I did try this, but it proved to not be the problem.
> ...
> Currently, it appears at this point that the settup_harddisks
> doesn't deal with /dev/mdX configurations.
>
> Is this something that's being planned, or, something that's even
> desirable?  I'd be willing to hack setup_harddisks to recognize these
> devices, and create the raid set prior to formatting the meta-device
> if that's the way to go.  Currently I have a very ugly hack of a
> scripts/CLASS/S## file which adds the line to the /etc/fstab, copies
> in the raidtab file, creates the raidset, and lays down the file
> system.
>
> However, it seems to me that this could all be done within
> setup_harddisks, no?
>
> What do people think?  Where should this go?