possible FAQ: setting file system parameters with part/logvol?

[Tim Mooney]

In regard to: RE: possible FAQ: setting file system parameters with...:

> Going along with what Chip said,  you will *have* to use pre because
> there doesn't seem to be a way to specify the mkfs options via the part
> command.

Thanks to both you and Chip for confirming what I suspected.  I was just
hoping there was some undocumented way to pass things through part/logvol,
since that would have made my life much easier.

We make heavy use of %post in all of our kickstart files, but although
I knew %pre existed, I had never needed to use it before.  I have now.

> The way I see it, is you have two options.
>
> 1) If the partition you need to use "custom" formatting options on does
> not contain any OS data, then just have part create the partition for
> you and re-format it in %post.  (Personally, I'd have part make a VG,
> but not LV, and create it during %post to speed up deployment time)
> 2) If you do require OS data, then you will need to calculate the size
> of the partition you need, then format them accordingly, then just have
> part use --noformat --onpart

The second option is essentially what I ended up doing.  Here's what my
partitioning section of my ks config files look like:



zerombr yes
#
# TVM: don't do anything to the disk label.
#
clearpart --none

#/boot
part /boot  --noformat --onpart=hda1

# swap
part swap   --noformat --onpart=hda2

# /
part    /   --noformat --onpart=hda3

# remainder for LVM
part pv.01  --noformat --onpart=hda4

volgroup localvg1 pv.01 --noformat

logvol /usr/local   --noformat  --name=local    --vgname=localvg1
logvol /tmp         --noformat  --name=tmp      --vgname=localvg1
logvol /var         --noformat  --name=var      --vgname=localvg1
logvol /home        --noformat  --name=home     --vgname=localvg1
logvol /u01         --noformat  --name=oracle   --vgname=localvg1




Here's the %pre I ended up using (don't laugh, I was pressed for time):



%pre
echo '***'
echo '*** Perform manual partitioning step now.'
echo '***'
sleep 99999



echo 'boot-alignment-check' > /dev/hda1
echo 'swap-alignment-check' > /dev/hda2
echo 'root-alignment-check' > /dev/hda3
echo 'vg-alignment-check' > /dev/hda4

echo '***'
echo '*** Perform alignment checks for boot/swap/root/vg now.'
echo '***'
sleep 99999



lvm.static pvcreate /dev/hda4
lvm.static vgcreate --alloc contiguous -s 8M localvg1 /dev/hda4

lvm.static lvcreate --alloc contiguous --name var   --size 36864 localvg1
lvm.static lvcreate --alloc contiguous --name tmp   --size 2048 localvg1
lvm.static lvcreate --alloc contiguous --name local --size 1024 localvg1
lvm.static lvcreate --alloc contiguous --name home  --size 2048 localvg1

# figure out how many free physical extents there are remaining, and use
# them up.
pe=`lvm.static vgdisplay localvg1 | \
     sed -ne 's+^.*Free *PE.*/ Size *\([0-9]*\) /.*$+\1+p'`

#lvm.static lvcreate --alloc contiguous --name oracle --extents $pe localvg1
lvm.static lvcreate --alloc contiguous --name oracle --size 24576 localvg1

echo 'var-alignment-check' > /dev/localvg1/var
echo 'tmp-alignment-check' > /dev/localvg1/tmp
echo 'local-alignment-check' > /dev/localvg1/local
echo 'home-alignment-check' > /dev/localvg1/home
echo 'oracle-alignment-check' > /dev/localvg1/oracle

echo '***'
echo '*** Perform alignment checks for var/tmp/local/home/oracle now.'
echo '***'
sleep 99999




mkfs.ext3 -j -L /boot -E stride=16 /dev/hda1
mkswap -L swap /dev/hda2
mkfs.ext3 -j -L / -E stride=16 /dev/hda3

mkfs.ext3 -j -L /var -E stride=16 /dev/localvg1/var
mkfs.ext3 -j -L /tmp -E stride=16 /dev/localvg1/tmp
mkfs.ext3 -j -L /local -E stride=16 /dev/localvg1/local
mkfs.ext3 -j -L /home -E stride=16 /dev/localvg1/home
mkfs.ext3 -j -L /u01 -E stride=16 /dev/localvg1/oracle

echo '***'
echo '*** Filesystems created, perform any remaining tests you wish now.'
echo '***'
sleep 3600





Some explanation of the %pre is probably in order.  First, each of the
four boxes I was kickstarting were actually RHEL4.6 Xen (fully) virtual
machines on a RHEL5.1 base host.  The RHEL5.1 host has about 300 GB of
SAN storage, and I created four LVs within that, and put each of the
virtual hosts directly on one of the LVs (kickstarting with Xen, the
LV appears as /dev/hda).

Within the %pre:

- I pause the %pre with sleep and manually switch to virtual console #2
   (bash prompt) and perform the partitioning manually.  I didn't have time
   to figure out how to script sfdisk to automate the partitioning.  That's
   something I plan to play with in the coming days.

   When I'm done with partitioning and have things the way I want, I
   find the pid of the sleep command and kill it.

- the echo commands write a bit of text to the beginning of each
   partition, and then a sleep pauses %pre again.

   I then use a utility on the RHEL5.1 base host to verify that
   each of the bits of text that were written to the start of the
   VMs partitions is aligned on a 64K boundary.  Since all of the
   partitions ultimately get their storage from a RAID5 volume with
   a 64K stripe cache, you pay a signficant performance hit if your
   partitions or LVs are not aligned on a 64K boundary.

- once I've verified that the partitions are aligned on 64K boundaries,
   I again switch to virtual console 2 in the kickstart and kill the
   sleep.

- the LVM commands run to create the PV, volume group, and my LVs, and
   then write a bit of text to the start of each of the LVs, and again
   %pre pauses

- switch back to the RHEL5.1 base host, and spot check that at least
   one of the LVs is aligned on a 64K boundary by checking for the bit of
   text that was written to the start of the LV.  If one LV is correctly
   aligned, all of them will be.

- kill the sleep, at which point mkfs runs to create the empty filesystems
   on the partitions and LVs, with the stride=16, as well as setting up swap.
   The stride is used to make the filesystem play nicely with a RAID5
   stripe cache of 64K.

- the final sleep really isn't needed, kill it and %pre ends and the
   kickstart actually begins.



Thanks again for your help.  With the suggestions you provided, I was
able to get these four VMs kickstarted over the past weekend, and I've
verified that their filesystems are all correctly aligned for the maximum
performance all the way through the storage stack (which in this case
is unbelievably deep).

Tim
-- 
Tim Mooney                                        Tim.Mooney at ndsu.edu
Information Technology Services                   (701) 231-1076 (Voice)
Room 242-J6, IACC Building                        (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164