Matthew Rosewarne on 14 Nov 2008 23:36:40 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Your recommendations

On Saturday 15 November 2008, JP Vossen wrote:
> One related point, make sure you *do* leave some space unallocated.  And
> that means you have to do it manually, because if you use the Ubuntu
> alternate CD and pick the LVM option, it's going to allocate all the
> space into one giant PV and LV.  The problems with that are that it's
> all one big partition, and without unallocated space you can't do
> snapshots, which are great for backups.  Here the bug I filed on the
> snapshot issue:

Yes, snapshots are indeed delicious.

> One other related point, give some thought to your LVM naming, you will
> thank yourself (and hopefully me) later.  Here is what I do (I don't
> always use all of these, this is just a naming example):
> 	Physical volume = vg_{hostname}

To nit-pick, that's a volume group, not to be confused with a physical volume.

> 	Logical volumes = lv_swap_1
> 			lv_root
> 			lv_home
> 			lv_var
> 			...

I like to have my LV names either match or include the FS's label, just for 
consistency and obviousness.  (Swap doesn't count)

> So your partitioning question now becomes, which directories should I
> break out into separate volumes?  For your "heavily loaded with mail
> (clamscan,spamassassin,mimedfang), dns, apache, mysql and storage"
> use-case, my example above might be OK.

There are a few imperative reasons to keep different dirs on different LV's:
	1. You want to have anything that is infrequently changed on a read-only FS 
to prevent accidents/nefariousness.
	2. You want more more fine-grained control of LVM snapshots.
	3. You want to isolate some task that you expect might take up the entire 
disk and interfere with other tasks.
	4. Profit?

You can sometimes use quotas for combating the 3rd problem, which can be more 
convenient than having different LV's.  That only works if the task has a 
dedicated user upon which you can apply the quota, which is often the case 
with services.

> Now, the catch is /boot, which can't be inside LVM, but which can be
> inside software RAID.  Here is the terse, but step-by-step details of a
> server I set up in VMWare.  It has only 2 physical disks, and it uses
> one large lv_root instead of being more partitioned as above.  But if
> the mailers don't mangle it too much and you can read it, it's a start
> (replace 'hostname' with your machine's hostname if you use my naming):

With GRUB 2, there is no longer a need for a separate /boot partition, as GRUB 
2 can load the kernel directly from an LV.

> I find it a pain to compute the values (i.e., extents) when creating the
> logical volumes.  I generally do a tedious trial and error, flipping
> between virtual consoles as needed to see error messages about space.
> If this isn't clear, try doing the above steps in a VM or on a test box
> and you'll see what I mean.  I mentioned that in the bug too.

You don't have to specify extents, you should be able to specify sizes (i.e. 
"10G" or "512M").

Attachment: signature.asc
Description: This is a digitally signed message part.

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --