Raid, reiserfs, and FAI
Devlin
devlin at softhome.net
Mon Jul 29 20:54:35 CEST 2002
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?
More information about the linux-fai
mailing list