Title:  Logical Volume Manager (LVM)

download

Logical Volume Manager

En av de tjänstemän (Enhetschefen) som åtalats för tjänstefel i samband med en ung killes död, då han inte tvångsomhändertogs enligt LVM trots att han uppfyllde alla kriterier, har nu dömts till 80 dagsböter. Socialsekreteraren däremot friades helt. Jag kan ju tycka att det är en klen dom, men samtidigt så tycker jag det är jävligt bra att man markerade att han misskött sitt arbete på ett grovt sätt, det är ju inte allt för ofta socialtjänstemän behöver stå till svars för de fel de gör trots att det sannolikt sker i stort sett dagligen runt om i landet att man nonchalerar tex föräldrars rop på hjälp med missbrukande ungdomar/unga vuxna, något som är helt emot den socialtjänstlag som finns.

Sen får man tycka vad man vill om att det var grabbens val att missbruka osv, men dessa lagar är till för att följas, och finns just för att många som är inne i ett missbruk inte klarar att hjälpa sig själv. Jag skulle önska att fler var tvungen att ta större ansvar för sina beslut, inte bara inom socialtjänsten utan också inom andra områden som tex rättspsykiatrin. Då kanske vi skulle få ett lite bättre samhälle både för de sjuka, anhöriga och behövande. All heder åt grabbens föräldrar som drev det vidare, det är inte alla som orkar gå hela vägen då det är så extremt segt att strida mot myndigheter. Den här grabben dog 2004, är det rimligt att det ska ta 5 år att konstatera att ett fel begåtts när det enda man behöver göra är att läsa på vilka kriterier som ska ligga till grund för ett LVM? Det är så uppenbart att man begått ett fel, det finns inga tveksamheter alls om det, så varför ska det ta sån tid?

I’ve been using Debian squeeze/sid for a while now (with apt-pinning) and for the past few days I’ve been facing the “no space left to write” problem. I used the default LVM2-based disk partitioning scheme offered by the Debian installer. I thought it was okay to have a 6.5G root partition and the rest for the swap and my home partitions. Looks like 6.5G wasn’t enough for me. And the root and home partitions used the ext4(!) file-systems.

Now, here’s how you go about reducing your home’s size and increasing your root’s size.

1. Reduce the filesystem size of the partition which has enough free space to spare using resize2fs.
2. Then reduce the logical volume in which this filesystem resides using lvreduce.
3. Now extend the logical volume in which the “starving” filesystem resides  using lvextend by the same amount you used in step 2.
4. Then simply issue resize2fs /dev/VGNAME/LVNAME which should simply fill up the unallocated space in the logical volume it resides.
5. (optional), if your reduced filesystem doesn’t mount due to a block-size mismatch, e2fsck it and apply step 4. to it.

Glad that it all worked out fine. I didn’t have to use a live cd to do this (was too lazy for that anyway). I dropped into a vt, unmounted my home (which has the “important” data) and performed steps 1 and 2 on it. My root was still mounted while I did steps 3 and 4 on it.

I have on occasion wanted to change the name of an LVM volume group (vg) name.  This is not so hard, but if the logical volumes are mounted as system filesystems (/ /var /usr etc)  then it’s a bit more trouble.  The following was performed on a Redhat Enterprise Linux 5.4 server, but similar steps could be followed on other systems

If the logical volumes could just be deactivated then ‘vgrename’ could be run on the live system.  Since / (or /var, /usr) cannot just be unmounted the system has to be rebooted in rescue mode.  The first install disk of RHEL will allow you to do this.  Make sure that you tell it not to detect any installs of RHEL so that the LVM stuff is not activated.  Once you get a shell prompt verify that the volume group is detected (vgscan) and that none of it’s logical volumes are active (lvscan).  vgrename can now be run:

vgrename <current vg name> <new vg name>

Before rebooting a little cleanup needs to be done.  Entries in /etc/fstab have to be changed to reflect the new volume group name and a new initial ramdisk has to be created.   The easisest way to do this is to reboot into rescue mode and let it detect the install of your RHEL system.  Once the shell comes up chroot into the mounted root (assuming the RHEL install was detected).  This should be:

chroot /mnt/sysinstall

Now edit /etc/fstab.  Then run:

mkinitrd –fstab=/etc/fstab <image name> <kernel version>

You should also edit your grub menu.ls to reflect the new name of the volume group that the root file systems is in.

That’s it!  Now reboot and the new volume group name will be in effect.

LVM (LOGICAL VOLUME MANAGEMENT)

LVM stands for Logical Volume Management.

Used to manage data on multiple disks.

Basically it is a file system.

Mainly used to manage database.

ID of LVM is   “8e”

Used where large storage space required.

Increased on line without data loss.

LVM configured in three layers:-

Layer 1 : Physical volume layer

Layer 2 : Volume group  layer

Layer 3 : Logical volume layer

LVM CONFIGURING STEPS

Create three partitions .(5GB each)

Refresh partition table.

Create physical volume layer of partitions.

Check physical volume layer.

Create volume group layer of partitions.

Check volume group layer and  size.

Create logical volume layer.

Check logical volume layer and size.

Format logical volume in ext3 file system.

Create any directory under /lvm (any name) and mount LVM  permanent in /etc/fstab file.

Refresh mounting table and check mounted lvm and size.

LVM CONFIGURING COMMANDS

]# fdisk /dev/sda        (Create three partitions)

~]# partprobe /dev/sda

~]# pvcreate /dev/sda5 /dev/sda6 /dev/sda7

~]# pvdisplay

~]# vgcreate vg /dev/sda5 /dev/sda6 /dev/sda7

~]# vgdisplay

~]# lvcreate -L 12GB -n data vg

~]# lvdisplay

~]# mke2fs -j /dev/vg/data

~]# mkdir /lvm

~]# vim /etc/fstab

/dev/vg/data               /lvm                  ext3      defaults   0 0

:wq!

~]# mount -a

~]#df -TH

~]# cd /lvm

~]# ll

LVM EXTEND STEPS

Create new partition.                    (Size 10GB)

Refresh partition table.

Create physical volume layer of new partition.

Check physical volume layer.

Check volume group layer name and size.

Add new partition in volume group layer.

Check volume group layer.

Check logical volume layer name and size.

Extend logical volume layer.

Check logical volume layer name and size.

On line format logical volume layer.

Check size of mounted LVM.

LVM ENTEND COMANDS

]# fdisk /dev/sda

~]# partprobe /dev/sda

~]# pvcreate /dev/sda8

~]# pvdisplay

~]# lvdisplay

~]# vgextend vg /dev/sda8

~]# vgdisplay

~]# lvdisplay

~]# lvextend -L+10GB -n /dev/vg/data

~]# lvdisplay

~]# resize2fs /dev/vg/data

~]# df -TH

El grupo de Amigos de la Biblioteca Ludwig von Mises (perfil en FB) ha organizado una venta de libros usados a precios fantásticos.  La actividad inició el lunes pasado y estará abierta hasta el día jueves, 29 de octubre.

Los libros están en venta en el lobby de la Biblioteca Ludwig von Mises de la Universidad Francisco Marroquín (6 Calle final, zona 10. Guatemala).

Yo compré 15 libros (novelas en inglés, filosofía y arte) y sólo pagué 100 quetzales.  Además, si les interesan novelas en inglés en paperback (esta es la mejor oferta) hay cientos de opciones para elegir y podrán llevarse 4 a tan sólo Q10.00

¡Espero que puedan visitar la venta de libros!

Никогда до прошлой зимы не сталкивлся с необходимостью поднимать софтовый рейд в линуксе. Когда делали оракловый сервер под КИС, изучали ОС IBM AIX 5L. Так вот  там в составе ОС, есть такое замечательное средство – LVM, позволяющее управлять томами, в том числе создавать программные зеркала, страйпы и т.п. Другое дело, что при использовании внешних хранилищ, вроде DS4700, надобность в софтовом рейде отпадает. Зеркалирование настраивается средствами системы хранения.
И вот той зимой понадобилось создать сервер для резервных копий. В качестве ОС был выбран Debian GNU/Linux 5.0, только вышедший. Задачка в общем то казалась не очень сложной, тем более, что в линуксе тоже есть LVM. Но не тут то было. Создал группу томов, добавил физические тома, начал создавать логические с зеркалированием. Тут то и оказалось, что LVM для использования зеркал требуется журнал.Для этих нужд LVM в AIX выделяет область внутри самого зеркального тома, а линуксовая версия предлагает создать отдельный логический том. Это мне не понравилось. Ставить эксперимент не стал, но предполагаю, что в случае смерти одного из винтов, LVM не сумел бы подняться.
На помощь пришел программный рейд на базе mdraid. С помощью этой программы, я создал программные зеркала из четырех пар винтов. Программа создает виртуальные диски /dev/md0, /dev/md1 и так далее. А эти устройства уже можно использовать в качестве физических томов для LVM.
Кстати, еще одна особеннось. В AIX в качестве физического тома может выступать сам винт. В Linux LVM требует наличие на винте раздела и использует уже этот раздел. С чем связано, не знаю.

В итоге всех этих махинаций я имею на севере зеркальный софтрейд на базе mdraid и гибкий LVM поверх этого рейда. Проводил испытания – все отлично работает при выдергивании винта и добавлеении резервного вместо него.

Socialdemokraterna lägger nu ett förslag om att satsa 90 miljoner på missbruksvården. Det handlar om ett långsiktigt åtagande kallat ett kontrakt för livet som är ett samarbete mellan den enskilde, socialtjänsten och statens institutionstyrelse. Kontraktet ska hjälpa till efter en LVM-placering.

Jag hoppas att mitt parti också är med på detta förslag. Ska vi kunna hjälp missbrukare till ett drägligt liv så behövs långsiktiga helhetslösningar. Idag är det ändå alldeles för ofta så att missbruksvården är för svår att få eftersom många kommuner försöker undvika institutionskostnader så länge som möjligt. Detta kan i värsta fall leda till dyra kostnader för samhället fast på andra konton än socialens, men framför allt kan det leda till onödigt lidande för den som missbrukar och dennes omgivning.

Men ska MP vara med på detta förslag hoppas jag även på en viss modifiering. Jag vill ha incitament för helhetssyn även för dem som inte börjar sina försök till ett annat liv med LVM. Det är bra om det finns fler möjligheter att välja att självmant sluta än att bara satsa på dem som är en fara för sitt eget liv.

I have had a number of virtual linux machines that have run out of disk space and have found it difficult in the past to find one solution to increasing the virtual disk and expanding free space into a logical volume.

The most recent example was when I needed to extend from 8GB to 20GB and using the Gnome Partition Editor, Gparted, would not work as it doesn’t currently have LVM support.

There are some linux commands that get around this problem so first I extended the VMware virtual disk.

Expand the disk

Turn off the virtual machine that you wish to administer.

Open a command prompt and change directory to C:’Program Files’VMWare’VMWare Server or C:’Program Files’VMware’VMware Workstation depending upon what product you are running.

Run this command to expand the virtual disk: vmware-vdiskmanager -x 20GB "My harddisk.vmdk"

In my case I would like to increase the disk to 20GB so substitute your value. Include the full file location for the vmdk file and use quotes if there are spaces in the folder and/or filename

The disk expansion should complete successfully

Restart the VMware virtual machine and open a terminal session

Issue the df -k command which here shows us that the logical volume is at 100% usage

We need to create a partition on /dev/sda

Type ls -al /dev/sda* which lists the existing partitions

Our new partition will be /dev/sda3

Type fdisk /dev/sda then type’n’ for new partition

Enter ‘p’ and 3 for the partition number (in this instance..obviously enter the partition number that matches your environment)

Also accept the default First and Last cylinders

Finally type ‘w’ to write table to disk and exit

If prompted to reboot then do so to ensure that the new partition table is written.

After a restart, type ls -al /dev/sda* to verify whether the new partition was created

Now that the partition has been created we need to create a physical volume and add it to the volume group

Type pvcreate /dev/sda3

Type vgextend VolGroup00 /dev/sda3

We need to extend the logical volume

Type vgdisplay

Which shows that there is 11.97GB free that we can add to the volume group

To extend the volume type lvextend -L+11.97G /dev/VolGroup00/LogVol00

I then had an error message that stated that there was ‘Insufficient free space: 384 extents needed but only 383 available’

After a quick search:

http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/nofreeext.html

It seems that I needed to select a slightly smaller size. I selected 11GB rather than 11.97GB which solved this problem.

Finally we need to resize the file system by typing resize2fs /dev/VolGroup00/LogVol00

Type df -k to see if the new space is available to the logical volume

The logical volume has now been resized and now has used space of just 35%!

I recently bought a new 1TeraByte hard disk, and tried to understand the possible ways to add it to my existing Ubuntu Linux system.  On a default system, even with separate home and root partitions, it is quite difficult to exploit the added space of a new drive: one could migrate the home partition to the new drive and expand the root partition to cover the whole old drive, but it is not a flexible nor scalable solution. On a Linux system with Logical Volume Management (LVM) instead, all I should do is add the new drive into the volume group to have the possibility to expand both partitions. LVM is a system that stays between the filesystems and the physical drives, and simplifies the management of separate physical volumes by adding abstraction layers (Volume Groups and Logical Volumes). All the information you might need on LVM can be found here: http://tldp.org/HOWTO/html_single/LVM-HOWTO/

One problem with LVM is that in order to resize the root partition, the root partition must be unmounted. The easiest way is to boot a Live CD and manage the partitions from there. The Ubuntu Live CD does not support LVM: in order to install an Ubuntu system with LVM, the alternate installer CD must be used. This CD lacks the live graphical environment of the default Ubuntu desktop CD, and instead offers a text-based installer; the alternate CD lacks also an easy way to manage partition without reinstalling. What I need is a CD that enables both LVM installation and LVM managing, and this tutorial will show how to create it.

There is a very handy and complete guide here to customize Ubuntu Live CD:

How to Customise the Ubuntu Desktop CD

In order to build the CD I used a VirtualBox virtual machine, but it is not necessary: you just need an Ubuntu machine and administration privileges. The hard disk occupation of the whole process, including the ISO images of the original Live CD and the custom Live CD, is around 3.5GB, so organize your hard disk space accordingly. I downloaded an Ubuntu Jaunty Jackalope desktop CD iso from the official site, and  I followed the guide literally for the sections:

• Extracting the CD content
• Extracting the Desktop system
• Prepare and chroot

Then, for the Customizations section, I uninstalled some secondary packages to free space for “lvm2″ package and then I installed it:

# apt-get purge gimp gimp-data
# apt-get purge gnome-games gnome-games-data
# apt-get install lvm2

I then wanted to install the graphical and user-friendly tool “system-config-lvm” package; the package is included under the “universe” section that is disabled by default. For this reason I opened the configuration file of the “apt” repositories with the command “nano /etc/apt/sources.list”, uncommented the deb lines of the “universe” section and saved. To have a glimpse of the functionalities of this GUI front-end for LVM you can take a look at the relative section in the redhat enterprise manual.

# apt-get update
# apt-get install system-config-lvm
# apt-get autoremove
# apt-get clean
# apt-get autoclean

I then recreate the filesystem image. Since I used Ubuntu Jaunty Jackalope, the kernel release version is 2.6.28-11-generic. You can discover your release using “ls /lib/modules”, because the name of that directory corresponds to the kernel version of the original Live CD;
change the following “mkinitramfs” command accordingly.

# mkinitramfs -o /initrd.gz 2.6.28-11-generic

Some commands to cleanup the Live CD…

# rm -rf /tmp/* ~/.bash_history
# rm /etc/resolv.conf
# proc ">umount /proc || umount -lf /proc
# umount /sys
# umount /dev/pts
# exit


Then, in the normal command prompt, I moved the filesystem image (initrd.gz) into the casper directory like the tutorial says:

$ sudo umount edit/dev || sudo umount -lf edit/dev
$ sudo mv edit/initrd.gz extract-cd/casper/


I then followed literally the “Putting the CD together” section, and at the end I had an iso image of a complete Ubuntu Live CD with LVM support.

I hope to find the time to do a screencast on how to install Ubuntu with this custom CD and how to modify an already installed LVM system.

So, after I got my laptop back, I decided to put that 500GiB hdd to good use, and opened up my laptop and swapped the drives (YOU DIDNT READ THAT!), and proceeded to reinstall my system from the backup 160GiB hdd (which Asus ended up not erasing at all… heh) Talking in IRC got me a few different methods of doing this. The easiest and final decision thanks to Ben (aka mathstuf of #fedora-kde) was:

Run on the source:
rpm -qa –qf “%{name}” > packagelist.txt

And on the target:
cat packagelist.txt | xargs yum install

Because the yum install of some 1700 packages took about an hour to setup of the download, and it took me three tries before I gave up due to dependancy hell, I decided to add just a tiny little –max-args 10 to the xargs, giving me a final command of `cat packagelist.txt | xargs –max-args 10 yum install` which worked beautifully after about two hours of installs.

After that getting /home off the device was fairly trivial, though it took me two runs because I missed the DOT dirs the first time around, I ended up with the following command:

/bin/cp -arvf /media/home/* /home/

The command references /bin/cp to get around Fedora’s default alias which is to include -i, which makes overwriting many files utter hell. After that I simply rebooted and started KDE, just like it’d been before

To mount the LVM Fedora creates on first install (HAL doesn’t detect LVMs):
su -
lvscan
vgchange -a y
mount /dev/vg_hostname/lv_root

The post is brought to you by lekhonee v0.7

את המערכת שלי העברתי ל-LVM לפני כשנה, בתקופה שהתעסקתי הרבה עם LVM על שרתים. כעת, אחרי שנה שלמה שלא נגעתי ב-LVM של לינוקס (התעסקתי עם מנגנונים דומים של חברות מסחריות), עלה אצלי הצורך להעביר את כל המידע מהדיסק שלי לדיסק חדש.

הבעיות:

• אני דיי חלוד עם LVM
• שני הדיסקים שלי (ישן+חדש) מכילים PV על כל שטח הדיסק.
• יש VG שונה על כל אחד מהדיסקים.
• אני צריך את המידע על הדיסק החדש, ולא יכול למחוק אותו.

תיאורטית, המצב אמור להיות פשוט – מזהים את הדיסק החדש, יוצרים עליו PV, מגדילים את ה-VG ומשתמשים ב-pvmove כדי להעביר את המידע בין הדיסקים. אך בגלל שעל הדיסק החדש כבר יש PV  בכל שטח הדיסק שעליו יושב VG נפרד, המצב הרבה יותר מסובך.

עם קצת בירורים, מסתבר שיש את הפקודה vgmerge שמאפשר למזג VG אחד לתוך VG אחר. רק צריך לוודא שיש מספיק מקום פנוי ושאין LVים באותו השם (ואם כן אז לשנות להם את השם). פשוט מאוד, אך מסתבר שבשביל זה צריך שהיה אותו גודל PE (גדול בלוק של ה-PV) בשני ה-VGים. מאחר וברירת המחדל עבור גודל ה-PE השתנתה מ-2M ל-4M, נתקעתי עם הגדרות שונות לכל VG.

כאן פחות או יותר התחיל סרט רע שכלל הרבה שינוי גודל ל-FSים, LVים ו-PVים כדי לאפשר את שינוי הגודל מ-2M ל-4M. כל המשחקים הובילו אותי להודעות שגיאה מעצבנות בזמן ניסיון לשנות את גדול הבלוק. ההודעות טענו שהגודל החדש אינו כפולה של גדול הבלוק, ולכן לא ניתן לבצע את השינוי. כנראה שמדובר בבאג, כי אין סיכוי ש-PV בגודל של מספר G עגולים, לא יתחלק ב-4M, אבל נשאיר את זה לפעם אחרת.

לאחר הרבה משחקים, שבהם בעיקר דאגתי לעצמי לתרגול פקודות LVM ו-FSים, פתרתי את הבעיה ע”י שינוי גודל הבלוק של ה-PV בדיסק החדש מ-4M ל-2M. השינוי היה קל ומהיר. לאחר שהתגברתי על הבעיה הזאת, נשאר להעביר את המידע עצמו עם pvmove.

אז כמה טיפים על pvmove (בעקבות בעיות בעבר). הראשון הוא שמומלץ להשתמש באופציה ה-verbose של הפקודה כדי לקבל דיווח על ההתקדמות, אחרת יש הרגשה שהכל תקוע. דבר שני, ביטול הפקודה לא נעשה עם CTRL+C אלא עם הרצת pvmove –abort ממסוף אחר (קצת בעייתי ב-Single User). ולבסוף, פקודות LVM אחרת יתקעו לכם בזמן הריצה של pvmove כתוצאה מנעילות.

הפקודה עובדת בצורה מסודרת, ומבטיחה כי גם בזמן תקלה, המידע לא ילך לאיבוד. תחילה מבוצע שיריון של שטח היעד כולו, כדי לראות שאפשר לבצע את המעבר. לאחר מכן ננעל שטח יעודי עבור ה-PE שרוצים להעביר והוא משוכפל לשטח החדש. לאחר השכפול מבוצעת מחיקה של השטח הישן. סה”כ העברתי כ-60G עם הפקודה ללא שום בעיות.

לסיום התהליך נשאר להעיף את ה-PV הישן, לשנות את גודל ה-PE חזרה ל-4M (הפעם עבר ללא בעיות) וזהו.

lvcreate -L 16 -n datavol vg01 —> 16mb

lvdisplay /dev/vg01/datavol

ls -l /dev/vg01 —> verify DSF

newfs -F vxfs /dev/vg01/rdatavol

mkdir /data

mount /dev/vg01/datavol /data

echo “/dev/vg01/datavol /data vxfs defaults 0 2″ >> /etc/fstab

pvcreate /dev/rdisk/disk40

mkdir /dev/vg01

chown root:root /dev/vg01

chmod 755 /dev/vg01

mknod /dev/vg01/group c 64 0×010000

chown root:sys /dev/vg01/group

chmod 640 /dev/vg01/group

vgcreate -s 16 /dev/vg01/group —>16mb

vgdisplay -v vg01

Identify Available disks on system

ioscan -fnkNC disk

ioscan -m dsf

ioscan -P health

Getting information about LVM volumes on the system

mount

strings /etc/lvmtab

bdf

Getting information abount the current LVM Objects

vgdisplay vg00

vgdisplay -v vg00 |grep “LV Name”

lvdisplay -v /dev/vg00/lvol1

Verify disk belongs to volume group which is inactive or not imported

pvdisplay -l /dev/disk/disk*

Da meine gesamte Festplatte mit LVM verschlüsselt ist, ist es bei einem Problem etwas komplizierter auf die Festplatte zuzugreifen.
Als Live-CD habe ich die Ubuntu 9.04 Desktop (alle Versionen abwärts haben Probleme mit dem X-Server) verwendet.

1. sudo apt-get install cryptsetup lvm2
2. sudo cryptsetup luksOpen /dev/sda1 root
3. sudo lvmdiskscan
4. sudo vgchange -ay
5. ls -l /dev/mapper
   crw-rw—- 1 root root 10, 63 May 2 11:43 control
   brw-rw—- 1 root disk 254, 0 May 2 11:50 DEVICENAME
   brw-rw—- 1 root disk 254, 3 May 2 11:58 vgcrypt-lvhome
   brw-rw—- 1 root disk 254, 1 May 2 11:58 vgcrypt-lvroot
   brw-rw—- 1 root disk 254, 2 May 2 11:58 vgcrypt-lvscratch
6. sudo mkdir /media/root-laptop/
7. sudo mount /dev/mapper/itrasha-root /media/root-laptop
8. Fertig!

Quelle: http://ragnermagalhaes.blogspot.com/2007/05/mounting-lvm-crypt-filesystem.html

Introduction

Everybody’s got an opinion, and I’m no different. After reading Trent’s piece yesterday, I thought I’d add my two cents as my partitioning scheme is quite complex (though I can think of several ways to make it worse). For newbies, some of this is unlikely something to try, but you might want to read anyway to get an idea of what can be done.

For starters, I have 1GB of physical RAM, and 4GB of swap space split over two drives. I have two 120GB drives that I use for my primary system that are split into 8 partitions (and a logical ninth). Most of these partitions mirror (RAID-1) each other so that if one drive fails, the other maintains the system until I can replace it. You may note that the swaps are not mirrored, but both swaps and the md08 array are encrypted. Like Trent, I intended a dual boot with Windows, so the first partition on sda is NTFS. (Of course, I haven’t actually had a Windows OS on that partition in about two years, but it’s nice to know I have it if I find a game that won’t play nice in Wine.) Also note that /boot is a mirrored partition, which keeps the data safe, but upon bootup the boot loader (LILO/GRUB) accesses only one of the two drives (i.e., sda3, not md3).

Some Explanations

My computer uses its swap space greedily despite my setting swappiness at 20. I often have a lot of memory intensive apps and commands going at once, so I use a lot of swap space. I also expect an upgrade in the future, so the large size is in preparation for that. The general rule of thumb is to have at least as much swap as your physical memory, if not double. This, however, is really geared towards laptops. Many use the suspend-to-disc feature which copies the contents of the physical memory to swap, then turns off the RAM to save battery life. This obviously requires as much unused swap space as used memory. So if you have nearly a full amount of RAM being used, and if that’s the case you’re probably using almost as much swap, you need nearly double the amount of physical memory in swap to accommodate the RAM’s data in order to suspend.

Author’s Note: A commenter has brought to my attention a rather serious error in the following paragraph that I dragged through to other parts of the article, including the conclusion. To fix it, I’ve opted for leaving the original paragraphs in place in their entirety though struck out, with revisions, where necessary, following the originals. I apologize profusely for the error, and my humiliation is profound. I considered a lengthy explanation of where that all came from, but it would sound too much like making excuses and backpedaling. So suffice it to say it’s not a bad idea to keep swap on a separate hard disk from the rest of your system, and also that when something doesn’t ring quite true, you should heed your inner voice and double check it before making notes, much less use those notes as a basis for published work. =D Again, terribly sorry, and please ignore the following struck passages.

With regards to location, it is best to keep your swap space at the beginning of your drive, but this isn’t so much about being at the beginning of the drive, as at the beginning of a platter, and being on a platter alone. Swap inevitably has far more read/writes than typical storage and operations, so you want the seek arm to travel the least amount of distance from rest to swap space and back. More importantly, you want the first seek arm working on swap while the others below it have access to the rest of your data. Otherwise, you would frequently have a situation where one arm is reading data from one side of the disc, and then because the computer wants to store it in swap for a while, writes to another part of the disc, this process would simply be repeated over and over for the whole size of the file. It’s much preferable to have the reads coming from one arm, and the writes going with another. For similar reasons, you don’t want your swap split onto two platters which is why the beginning of a platter is suggested. One could choose to create a swap partition at the beginning of the second platter of one’s hard drive and have the same results, but that takes a certain level of knowledge about the exact starting point of the second platter which most people won’t bother to find. It’s easiest to keep swap at or near the beginning of the drive so you can be fairly confident you’re in good shape. What isn’t suggested often, however, is to keep any rarely used partitions near the beginning as well to avoid read/writes with the same arm.

For example, my dual HDDs have four platters (each) which makes each platter about 30GB, and this works out to swap being on the first platter by itself most of the time as my first partitions are Windows/spare (which are generally unused), the swaps, /boot (which is only used at boot time), and a partition I call slackalt that serves as a nearly complete copy of my working Slackware system. I use the alternate for when I break something on my primary system, and booting into a system nearly identical to my own to do repairs is much preferable to using a live CD of a foreign system. (This partition can also serve as a location for installing alternate Linux distros when the mood takes me to experiment.)

Next page: My Partitions

My Partitions

I have explained the sda/b1 as being Windows/spare, sda/b2 as two swap partitions, and the mirrored sda/b5 as an alternate OS. The extended partition mentioned by Trent which is annoying, but basically unseen, is sda/b4.

My first partitions are Windows/spare (which are generally unused), the swaps, /boot (which is only used at boot time), and a partition I call slackalt that serves as a nearly complete copy of my working Slackware system. I use the alternate for when I break something on my primary system, and booting into a system nearly identical to my own to do repairs is much preferable to using a live CD of a foreign system. (This partition can also serve as a location for installing alternate Linux distros when the mood takes me to experiment.) So the sda/b1 are for Windows/spare, sda/b2 are the two swap partitions, and the mirrored sda/b5 are an alternate OS. The extended partition mentioned by Trent which is annoying, but basically unseen, is sda/b4.

Now for the tricky part. My actual Slackware OS I have split into mirrored partitions I name boot (/boot), root (/, /bin, /dev, /etc, /lib, /media, /mnt, /proc, /root, /sbin, /sys), apps or applications (/opt, /srv, /usr), var or variable (/tmp, /var), and home (/home). It is fairly common to put /home and /boot on different partitions/drives. It is not so common to do as much as I have. What I have essentially done is separate out the top-level directories that change frequently from those that do not.

There is also a cryptographic element at work, so here seems an opportune time to explain. Frequently, when you enter some passwords into your system, they are transferred to, and stored, in physical memory. They can remain there until your computer is turned off, and even then, using some techniques, someone could get to them. There is little you can do about RAM itself, but because your computer swaps memory onto your hard drive, sometimes those passwords can be stored in swap. This would allow anyone who has access to your drive to take a picture of it at any time, then go about trying to find your passwords in the swap partition. It is for this reason that it is a good idea to encrypt swap. Similarly, passwords can end up in /tmp and even /var, and likewise it is also not a bad idea to encrypt them as well.

Usually, swap is encrypted each time at bootup with a random key and erases what was there from last time. But because we care about getting the contents of /tmp and /var back from session to session, we must use the same key(password) to get access to them each time. It is possible to have put them each on their own partition, but then I’d have to use two passwords to get to them. Thus, it was easiest to use a single partition for the two top-level directories I wanted encrypted, and encrypt the whole thing using one password.

Going Further

You may ask why I didn’t just encrypt the whole OS? I only have 1GB of RAM at the moment and I use it pretty well already. I simply wasn’t willing to encrypt a lot of stuff that doesn’t really need it and suffer a performance hit that extensively.

Now this is the really interesting part and it affects partitioning directly. How you set up your system will depend on how much encryption you want to use.

1. Swap will pretty much always get its own partition because you want to use a randomly generated key each time. But! you might not want people knowing that that part of the hard drive is swap because then they can go to work on it trying to decrypt passwords there as compared to searching through the whole drive. So if you’re going to encrypt the whole drive, you might want that encryption done first, and then potentially encrypt swap with its random key within the first (though this would double the encryption on it and really hurt performance). More, suspend to disk on laptops can have issues with encrypted swap. I am by no means an expert in this particular, so I’ll refer you to Google and more knowledgeable hands.
2. /boot is almost essentially unencrypted as the computer has to access it before it knows how to start decrypting anything. But! you might put the kernel image and other necessary files in a ramdisk and store it on a CD or flash drive, and then boot from there, allowing you to completely encrypt your system drive.
3. /tmp and /var are security holes. Many programs don’t think twice about storing potentially dangerous information there; sometimes even unencrypted passwords, but more often recent document lists and such that you would prefer no one know existed at all.
4. /opt can sometimes have similar security holes.

Ultimately, how many passwords you want to enter is going to determine how many partitions you wish to use. Potentially, you could encrypt each partition with a different password, and then have to enter all of them each time you reboot. Most people are only going to want to enter one password so most people will make two partitions, one for /boot and one for the rest of the system. What you do is create a single partition, encrypt it, and then use LVM (Logical Volume Management) to make all the logical partitions you want within the encrypted physical partition.

This is all independent of RAID arrays/mirrors (which also happen to be logical volumes of a sort). In the example above you would simply create the raid mirror first, then encrypt it, partition that crypto device into logical volumes via LVM, then format those with your file system of choice (e.g., ext3), mount each, and use. In other words, the mirror is transferring encrypted data to the second disk. It doesn’t care that there are partitions within or not, it’s mirroring the encrypted bits exactly as they are.

It’s pretty crazy (and cool), but they’re all just imaginary devices pointing to other imaginary devices pointing to real devices. Which means they’re all basically links at the device mapper layer of the kernel, and you can link however many times you like. Taking this further, you could mirror two sets of drives -> encrypt each mirror -> LVM partitions each mirror -> raid stripe one partition from one mirror with another partition from the second.

Next page: Back To Me

Back To Me

So back on my computer, I decided encrypting swap, /tmp, and /var was enough security for me given my hardware limitations. The /boot was separated for safety’s sake, and in anticipation of that future memory upgrade, at which time I will encrypt the whole thing and /boot will need to remain separate from that encryption. Why then did I decide to separate /opt, /srv, and /usr to a different partition? Well, it’s because those are the three top-level directories that change frequently (and take up the most space) on a system. The other partition is essentially static so for one, it makes security checking for changes (that someone else might have made) that much easier. And second, splitting the two sets of directories means that the active partition is physically separated from the inactive. This makes the hard drive’s seek arm(s) stay within a smaller area, having less distance to travel most of the time. My home/data directory has its own partition for the same reasons. Many would argue that the performance gain is minimal, and I agree, but more than the slight performance gain is the diminished wear and tear on the drive. Everyone eventually has failed drives. The most basic cause for this is moving parts. Any extra time I can get out of them by causing less stress on those parts is worth it in my book.

So back on my computer, I decided encrypting swap, /tmp, and /var was enough security for me given my hardware limitations. The /boot was separated for safety’s sake, and in anticipation of that future memory upgrade, at which time I will encrypt the whole thing and /boot will need to remain separate from that encryption. Why then did I decide to separate /opt, /srv, and /usr to a different partition? Well, it’s because those are the three top-level directories that change frequently (and take up the most space) on a system. The other partition is essentially static so it makes security checking for changes (that someone else might have made) that much easier. And over almost everything there is the redundancy of a RAID mirror so that if one drive dies, the system can live on.