Smokes your problems, coughs fresh air.
It’s that time again…
First my grub broke. So I had to type my config manually:
root (hd0,0) kernel /vmlinux26 root=/dev/mapper/lvmopraid-root initrd /kernel26.img boot
Then my logical volumes can’t be found. Type this in the recovery shell:
lvm lvchange -a e lvmopraid
I commented on an archlinux bug about this.
And then nothing started anymore on boot, because everything is migrating to systemd (as opposed to systemv), without telling me… Still working on fixing that.
Hard disks are being released that abandon the long-established standard of 512 byte sectors. I just got two Western Digital WD15EARS ones, which uses 4 kB sectors. Western Digital Refers to this as “Advanced Format”. This poses some serious problems. I will describe those, and what I did to ‘solve’ it.
This article is as much for myself as for other people correcting me. So, if you see faults, let me know 🙂
First, you may want to read this IBM article and this LWN article. Reading these articles is important to understand this issue. Too summarize a bit, hard disks can’t really have 4 kB sectors, because then BIOS, bootloaders, operating systems, partition software and who knows what will just go beserk. So, they still report a sector size of 512 bytes. This emulation presents certain performance issues (explained in the links), which can only be avoided by aligning the filesystems on disk, which the IBM article explains well. In short, I configured fdisk to 224 heads and 56 sectors. This aligns the partitions properly. Do remember, however, to start at cylinder 2 for your first partition, otherwise there isn’t enough space for the bootloader.
Now, what happens if you don’t put a file system on your partition, but make a software RAID1+LVM out of it? It gets a lot more complicated to align the filesystem blocks this way, because of all the layers. I did the following:
First I created the aligned partition with fdisk on two disks. Then I made a RAID1 array out of it. Luckily, Linux MD has the ability to store the RAID superblock at the end of the partition. It can also store it at the beginning, but you shouldn’t do that! The RAID superblock is 256 bytes + 2 bytes per drive long, which means one logical sectors, which in turn means that the start of the MD partition is in the middle of a 4 kB sector on disk. You can use metadata format 1.0 or 0.9 to put the superblock at the end of the disk (see mdadm man page).
Then it’s time to create the logical volume. When preparing the RAID1 partition for use in the volume group, give pvcreate the –dataalignment 4096 option. Then, with “pvs -o +pe_start”, you should be able to see where the first PE (physical extent) starts. I accidentally created mine with alignment 8, but the first extent is at 136.00 kB (139264 bytes), which is divisable by 4096.
Then, I created the volume group with an extent size of 4MB. 4 MB is also divisible by 4096. Logical volumes are created as multiples of the extent size, so you can now create them at will, and they will be aligned.
When creating a RAID array that deals with striping, be sure to make the stripe size a multiple of 4 kB. I guess this also applies to logical volumes with striping.
What I still would like to know, is whether the file system journal is also made up of 4 kb blocks. Also, the RAID array’s write intent bitmap (if you have one) is also still unclear to me. Where is that stored? Does it write in multiples of 4k?
I just installed Arch Linux on a RAID1+LVM, which involved some work. There already is a nice article about it, but I wanted to summarize for myself.
Arch has no GUI or menu for you to do this. So, when the installer has started, just go to another VT and create the RAID+LVM.
In my first attempt, I created one RAID partition with LVM, from which I intended to boot using Grub2, since it understands LVM and RAID. However, the grub installer kept saying there was no mapping for /dev/mapper/lvmroot or something, so I decided to make two partitions: one boot and one rest, which was meant as physical volume for the LVM. The advantage of linux software raid (when you store the superblock at the end of the partition, at least), is that grub can access it like a normal disk; it doesn’t need to know RAID).
After the array was made using something like:
mdadm --create /dev/md0 -l 1 -n 2 -x 0 -e 1.0 /dev/sda1 /dev/sdb1 mdadm --create /dev/md1 -l 1 -n 2 -x 0 -e 1.0 /dev/sda2 /dev/sdb2
It was time to create the LVM. So, I ran (don’t know the exact syntax, so this is an abstraction):
pvcreate /dev/md1 # In my research for my initial lvm problem, I found people who had # problems with dashes in the volume group name, so I don't # use those anymore... vgcreate lvmonraid /dev/md1 lvcreate -n root -l [wanted size/extentsize] lvmonraid lvcreate -n home -l [wanted size/extentsize] lvmonraid lvcreate -n swap -l [wanted size/extentsize] lvmonraid
Extent size is normally 4 MB, so a 40MB partition would have “-l 10”. You can also supply sizes in bytes, but that is not only inprecise because it gets rounded to the extent size, but I also noticed bugs in what metric and binary units were supposed to be; it seemed like the command line options don’t differentiate between G and g, for instance, and they’re all GiBi, whereas the –units option does.
When this is done, you can configure the block devices in arch to assign the purpose.
When the installation is almost done, it asks to modify some configuration files. This is important, otherwise the initramfs won’t load the LVM. You need to:
Then it will create the ramdisk. The next thing is installing Grub. The config file it makes is fine, except you need to add (hd0,0) after the empty “root” directive, twice. Installing grub fails because of the RAID, so you have to do that by hand:
# grub grub> root (hd0,0) grub> setup(hd0) grub> root (hd1,0) grub> setup (hd1)
That should be it, basically. I actually did a lot more because of my new Western Digital WD15EARS disk with 4 kB sectors, but I’ll write about that soon.
© 2024 BigSmoke
Theme by Anders Noren — Up ↑
Recent Comments