[Date Prev][Date Next] [Thread Prev][Thread Next]
RE: possible FAQ: setting file system parameters with part/logvol?
- From: Tim Mooney <Tim Mooney ndsu edu>
- To: Discussion list about Kickstart <kickstart-list redhat com>
- Subject: RE: possible FAQ: setting file system parameters with part/logvol?
- Date: Mon, 31 Dec 2007 16:40:57 -0600 (CST)
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
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:
# TVM: don't do anything to the disk label.
part /boot --noformat --onpart=hda1
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):
echo '*** Perform manual partitioning step now.'
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 '*** Perform alignment checks for boot/swap/root/vg now.'
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 '*** Perform alignment checks for var/tmp/local/home/oracle now.'
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 '*** Filesystems created, perform any remaining tests you wish now.'
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
- 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
- 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 Mooney Tim Mooney 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
[Date Prev][Date Next] [Thread Prev][Thread Next]