[gentoo-amd64] conversion sda to lvm2 questions

[gentoo-amd64] conversion sda to lvm2 questions

[Beso]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

i'd like to commute my laptop system to lvm2, but before doing that i'd like
some hints.
first, i'd like to know if there's a way of passing an existing gentoo
installation on a hda disk going through the sda stack (i needed to do that
cause it was the only thing that fixed a problem with my ata disk going only
on udma-33 after kernel 2.20) with sata-pata piix controller which is still
experimental. i've taken a look around but haven't actually seen a document
explaining if it is possible to do that and how to do that.
second, i'd like to know if there's a need for a raid enabled motherboard
and more than one disk to go on lvm. i only have a 100gb disk that i'd like
to convert to lvm with no raid.
and last, does it make sense doing a passage to lvm? i currently run into
some problems with my root partition that gets filled and that i always have
to watch the free space on it, so if i don't pass to raid i'll try to
duplicate the partition on a greater one.
i was forgetting: i'd like to use it on amd64. is there any problem? i have
seen around some problems with lvm and amd64 some of them marked as solved,
so i'd like to know if there could be problems with this arch.
thanks for your help.

-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 1321 bytes --]

Re: [gentoo-amd64] conversion sda to lvm2 questions

[Mark Haney]

Beso wrote:
> i'd like to commute my laptop system to lvm2, but before doing that 
> i'd like some hints.
> first, i'd like to know if there's a way of passing an existing gentoo 
> installation on a hda disk going through the sda stack (i needed to do 
> that cause it was the only thing that fixed a problem with my ata disk 
> going only on udma-33 after kernel 2.20) with sata-pata piix 
> controller which is still experimental. i've taken a look around but 
> haven't actually seen a document explaining if it is possible to do 
> that and how to do that.
> second, i'd like to know if there's a need for a raid enabled 
> motherboard and more than one disk to go on lvm. i only have a 100gb 
> disk that i'd like to convert to lvm with no raid.
> and last, does it make sense doing a passage to lvm? i currently run 
> into some problems with my root partition that gets filled and that i 
> always have to watch the free space on it, so if i don't pass to raid 
> i'll try to duplicate the partition on a greater one.
> i was forgetting: i'd like to use it on amd64. is there any problem? i 
> have seen around some problems with lvm and amd64 some of them marked 
> as solved, so i'd like to know if there could be problems with this arch.
> thanks for your help.
>
> -- 
> dott. ing. beso 
Here's my $0.02.  LVM is great is you need better fault tolerance.  i.e. 
a RAID setup.  I have LVM volumes on our SAN (20TB or so @ RAID 5) and I 
have less trouble out of it than a couple of RAID systems I have that 
are straight xfs.  That said I do not know about the first part, I've 
never tried it.  For the second part, a RAID enabled MB would be fine if 
you plan on going RAID at some point.  I don't normally get my RAID on 
the motherboard simply because I have more control over what controller 
to put in the system to make sure it's compatible with various flavors 
of linux.  I run LVM at home in a RAID5 config and I've had to extend / 
a couple of times, so it is beneficial in that respect.  You can do that 
as well with xfs or a clustered fs (like gfs from RH), but LVMs seem to 
be a little more painless in my experience.

I run almost exclusively 64-bit systems and distros from *BSD to SuSE to 
Fedora (and gentoo) and I've never seen any problem at all with LVM in a 
64-bit environment.  My SAN runs on a dual opteron box and it handles 
2TB of data a day with no trouble out of LVM.

HTH.


-- 
Mark Haney
Sr. Systems Administrator	
ERC Broadband


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] conversion sda to lvm2 questions

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 3065 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Beso wrote:
>> second, i'd like to know if there's a need for a raid enabled
>> motherboard and more than one disk to go on lvm. i only have a 100gb
>> disk that i'd like to convert to lvm with no raid.

I recommend using software RAID unless you go all the way and get one of
those really fancy (expensive) RAID cards.  Honestly, software RAID has
some advantages over even the expensive setups, although a few
disadvantages as well.  I definitely wouldn't use the RAID built-into a
motherboard - it is effectively software RAID anyway and you're tossing
the flexibility of linux software RAID.

And LVM works fine without RAID - I've used it that way without issue at
all.  Of course, you have no protection so if you have a partition split
across two disks without RAID you lose data no matter which drive fails.

LVM is all about taking one pool of block devices and chopping it up
into a different pool of block devices - that's all.  You could run LVM2
on a floppy disk, on a USB drive, or whatever.  You could use LVM2 to
combine a floopy disk, an mp3-player, and a USB flash drive into a
single storage pool and then split it into a whole bunch of read-only
partitions.  It really has nothing to do with RAID other than the fact
that a RAID gives you one really big block device that is inconvenient
to use on its own.

One thing I haven't done is run boot/root on LVM2 - you might want to
look into that.  It might work with a initrd - I never bothered with
those so I keep it simple.  Besides, I keep little to nothing on my 1GB
root partition so it never fills up (root only contains /bin, /sbin,
/root, /lib, and /etc).


>> and last, does it make sense doing a passage to lvm? i currently run
>> into some problems with my root partition that gets filled and that i
>> always have to watch the free space on it, so if i don't pass to raid
>> i'll try to duplicate the partition on a greater one.

I'd recommend lvm for anybody doing anything at all.  It gives you a
whole lot more flexibility with your disk space.  If all your data is on
lvm and you want to add a raid later, or just add some new non-raid
drives, moving your data around becomes trivial (even with the system
running in full production).  Growing and shrinking partitions is
trivial as long as your filesystem supports it (I tend to use ext3 for
this reason - I don't think anything else supports both growing and
shrinking).

>> i was forgetting: i'd like to use it on amd64. is there any problem? i
>> have seen around some problems with lvm and amd64 some of them marked
>> as solved, so i'd like to know if there could be problems with this arch.
>> thanks for your help.

Maybe in the early dawns of time there were problems with lvm and amd64,
but I haven't experienced them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHD1KnG4/rWKZmVWkRAmowAJ9zk0Y71XPxfnopJY2El45nu5GpXgCgldZg
SiSjzsVfBCcDwy5UtE6Cj1I=
=CPm6
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

[gentoo-amd64] Re: conversion sda to lvm2 questions

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560710111422ne24dda4gf8bfd77dbd07f556@mail.gmail.com, excerpted
below, on  Thu, 11 Oct 2007 23:22:28 +0200:

> i'd like to commute my laptop system to lvm2, but before doing that i'd
> like some hints.

I run LVM on RAID, so let's see... =8^)

> first, i'd like to know if there's a way of passing an existing gentoo
> installation on a hda disk going through the sda stack (i needed to do
> that cause it was the only thing that fixed a problem with my ata disk
> going only on udma-33 after kernel 2.20) with sata-pata piix controller
> which is still experimental. i've taken a look around but haven't
> actually seen a document explaining if it is possible to do that and how
> to do that.

I don't know that specific controller, but in general, if it's the 
correct libata SATA/PATA driver, the conversion from using the old IDE 
drivers is pretty straightforward.  On the kernel side, it's just a 
matter of selecting the libata driver instead of the ide driver.  

Configuring mount-devices, you use /dev/sdX or /dev/srX, depending.
(I'm not actually sure which one IDE drives use -- I run SATA drives but 
have my DVD burners on PATA still, using the libata drivers, and they 
get /dev/srX not /dev/sdX.)  Basically, try both from grub and see which 
works.  Once you figure out which devices it's using (srX or sdX), you'll 
need to setup your fstab using the correct ones.

Keep in mind that it's possible your device numbering will change as 
well, particularly if you already had some SATA or SCSI devices.  That's 
the most common problem people run into -- their device numbers changing 
around on them, because the kernel will load the drivers and test the 
drives in a different order than it did previously.  Another variation on 
the same problem is that devices such as thumb drives and MP3 players 
typically load as SCSI devices, so once you switch to SCSI for your 
normal drives, you may find the device numbering changing depending on 
whether your MP3player/thumb-drive is plugged in or not at boot.  One 
typical solution to this problem, if you find you have it, is using the 
other shortcuts automatically created by UDEV.  Here, I use /dev/disk/by-
label/xxxxx for my USB drive mount-devices in fstab, thus allowing me to 
keep them straight, and access them consistently regardless of whether I 
have one or more than one plugged in at once.

Finally, there's one more possible complication.  SCSI drives are 
normally limited to 15 partitions, while the old IDE drivers allowed 63.  
If you run >15 partitions, better do some reconfiguring... but you're 
already on the right track, as that's right where LVM comes in! =8^)

> second, i'd like to know if there's a need for a raid
> enabled motherboard and more than one disk to go on lvm. i only have a
> 100gb disk that i'd like to convert to lvm with no raid.

LVM and RAID are two different layers.  While it's common to run LVM on 
top of RAID, it's not necessary at all.  It's perfectly fine to run LVM 
on a single drive, and in fact, a lot of folks run LVM not because it 
helps manage RAID, but because it makes managing their volumes (think 
generic for partitions) easier, regardless of /what/ they are on. =8^)

[I reordered this and the next question]
> i'd like to use it on amd64. is there any problem? i have seen around
> some problems with lvm and amd64 some of them marked as solved, so i'd
> like to know if there could be problems with this arch. thanks for your
> help.

I've had absolutely no issues at all with LVM on amd64, here.  Once 
configured, it has "just worked".  Note that I'm running LVM2 and NOT 
running LVM1 compatibility mode, as I setup LVM long after LVM2 was the 
recommended deployment.  It's possible/likely that the amd64 problems 
were long ago, with LVM1 configurations.

> and last, does it make sense doing a passage to lvm? i currently run
> into some problems with my root partition that gets filled and that i
> always have to watch the free space on it, so if i don't pass to raid
> i'll try to duplicate the partition on a greater one.

As I mentioned, a lot of folks swear by LVM for managing all their 
volumes, as once you get the hang of it, it's simply easier.  They'd 
CERTAINLY say it's worth it.

There is one caveat.  Unlike RAID, which you can run your root filesystem 
off of, and /boot as well for RAID-1, LVM requires user mode 
configuration.  Therefore, you can't directly boot off of LVM.  I don't 
believe there's a way to put /boot on LVM at all because to my knowledge, 
neither grub nor lilo grok lvm (tho it's possible I'm wrong, I've just 
never seen anything saying it's possible, neither have I had anyone 
correct this statement of belief when I've made it in the past).

The root filesystem CAN be on LVM, but it requires running an initrd/
initramfs and proper configuration thereof in ordered to do.  Here, I 
configure my own kernel directly (without using genkernel or whatever), 
and while I understand the general idea, I've never taken the time to 
figure out initrd/initramfs as I've never needed it, and strongly prefer 
continuing to omit that extra level of complexity from my boot process if 
at all possible.  Thus, while I have my root filesystem (and my emergency 
backup image of same) on RAID (which the kernel can handle on its own 
entirely automatically in the simple case, or with a couple simple kernel 
command line parameters in more complex situations), I deliberately chose 
NOT to put my root filesystem on LVM, thereby making it possible to 
continue to boot to the main root filesystem directly, no initramfs/
initrd necessary, as it would be if the root filesystem was on LVM.

So... at minimum, you'll need to have a traditional /boot partition, and 
depending on whether you want to run LVM in an initramfs/initrd or would 
prefer to avoid that, as I did, you may want your root filesystem on a 
traditional partition as well.

FWIW, my root filesystems (the main/working copy, and the backup copy... 
next time I redo it, I'll make TWO backup copies, so I'll always have one 
to fall back to if the worst happens and the system goes down while I'm 
updating my backup copy) are 10 GB each.  That includes all of what's 
traditionally on /, plus most of /usr (but not /usr/local, /usr/src, or 
/usr/portage), and most of /var (but not /var/log, and I keep mail and 
the like on its own partition as well).  

The idea with what I put on / here was that I wanted keep everything that 
portage touched on one partition, so it was always in sync.  This was 
based on passed experience with a dying hard drive in which my main 
partition went out.  I was able to boot to my backup root, but /usr was 
on a separate partition, as was /var.  /var of course contains the 
installed package database, so what happened is that what the package 
database said I had installed only partly matched what was really on 
disk, depending on whether it was installed to /usr or to /.  *That* 
*was* *a* *BIG* *mess* to clean up!!!  As a result, I decided from then 
on, everything that portage installed had to be on the same partition as 
its package database, so everything stayed in sync.  With it all in sync, 
if I had to boot the backup, it might not be current, but at least the 
database would match what was actually installed since it was all the 
same backup, and it would be *far* easier to /make/ current, avoiding the 
problems with orphaned libraries and etc that I had for months as a 
result of getting out of sync.

Of course, as an additional bonus, since I keep root backup volumes as 
well, with the entire operational system on root and therefore on the 
backups, if I ever have to boot to the backup, I have a fully configured 
and operational system there, just as complete and ready to run as was my 
main system the day I created the backup off of it.

So FWIW, here, as I said, 10 gig root volumes, designed to everything 
portage installs along with its package database is on root, and 
according to df /:

Filesystem            Size  Used Avail Use% Mounted on
/dev/md_d1p1          9.6G  1.8G  7.8G  19% /

So with / configured as detailed above, at 19% usage, 10 gigs is plenty 
and to spare.  I could actually do it in 5 gig and still be at <50% 
usage, but I wanted to be SURE I never ran into a full root filesystem 
issue.  I'd recommend a similar strategy for others as well, and assuming 
one implements it, 10 gig should be plenty and to spare for current and 
future system expansion for quite some time.  (While I only have KDE 
installed, even if one were to have GNOME AND KDE 3.5.x AND the upcoming 
KDE 4.x AND XFCE AND..., even then, I find it difficult to see how a 10 
gig / wouldn't be more than enough.)

Swap:  If you hibernate, aka suspend to disk, using the swap partition 
for your suspend image, I /think/ it has to be on kernel-only configured 
volumes, thus not on LVM.  At least with the mainline kernel suspend 
(which I use, suspend2 may well be different), the default image is half 
a gig.  However, by writing a value (number of bytes, why they couldn't 
have made it KB or MB I don't know...) to /sys/power/image_size, you can 
change this if desired.  If you make it at least the size of your memory 
(but not larger than the size of the single swap partition it's going 
to), you won't lose all your cache at suspend, and things will be more 
responsive after resume.  The cost is a somewhat longer suspend and 
resume cycle, as it's writing out and reading in more data.  Still, I've 
found it well worth it, here.  You can of course create additional swap 
space on the LVM if you want to later, but can't use it as suspend image, 
and the additional layer of processing will make it slightly less 
efficient (at least in theory, but given the bottleneck is the speed of 
the disk, in practice, it's going to be very slight if even measureable).

So... assuming you deploy based on the above, here's what you will want 
directly on your hard drive as partitions:

/boot		128 meg, half a gig, whatever...

/	\	These three, 10 gig each,
rtbk1	 }	again, as partitions
rtbk2	/	directly on the hard drive.

swap		Size as desired.  Particularly if you suspend to disk,
		you'll want this on a real partition, not on LVM.

LVM2		Large partition, probably the rest of the disk.
		You then create "logical volumes" managed with LVM2
		on top of this, and then mkfs/format the created logical
		volumes with whatever filesystems you find most
		appropriate, in whatever size you need.

If you keep some extra space in the "volume group", you can then expand 
any of the volumes within as necessary.  When you do so, LVM simply 
allocates the necessary additional space at the end of what's already 
used, marking it as in use and assigning it to the logical volume you 
want to expand.

If you run out of space on the drive, you can then add another drive (or 
partition on another drive, or RAID device, or whatever, as long as it's 
a block device, LVM should be able to use it), then tell LVM about it and 
that you want it added to your existing volume group, and you'll have 
additional room to continue to expand into, all without worrying about 
further partitioning or whatever.

Correspondingly, if you want to reorganize your logical volumes (LVs) 
under LVM, moving the data to other volumes and deleting the freed LVs, 
that's fine too.  Simply do that.  The space freed up by the deleted LV 
is then free to be used by other logical volumes as necessary.  Just tell 
LVM you want to do it, and it does it.  All you worry about is the 
available space to expand LVs into, and LVM takes care of where they are 
actually located within the space you've told it to manage as that volume 
group (VG).

THE BIG CAVEAT, however, is simply that with LVM managing all of it, it's 
all too easy to just continue adding drives to your existing volume 
groups, forgetting how old your first drive is, and that it'll eventually 
wear out and fail.  This is what's so nice about putting LVM on RAID, 
since the redundancy of RAID allows drives to fail and be replaced, while 
the LVM continues to live on and adapt to your ever changing and normally 
ever growing data needs.

As long as you catch it before the failure, however, you can simply 
create a new VG (volume group) on your new drive (or partition, or set of 
drives or partitions, or RAID device(s), or other block device(s)), size 
it as necessary to hold your existing data, and copy or move stuff over.  
As with the above, you'll have to worry about any non-LVM partitions/
volumes/whatever, but the bulk of your data including all your user and/
or server data will be in the LVM, with the flexibility it provides, so 
even with the limited number of non-LVM partitions I recommended above, 
it'll still be vastly easier to manage upgrading drives than it would be 
if you were handling all that data in individual partitions.

So the big thing is, just because it's all on LVM now, and easy to expand 
to a new drive, doesn't mean you can forget about the age of your old 
drive, and that if you simply expand, the old drive will eventually fail, 
taking all the data on it, and your working system if you've not made 
proper arrangements, with it.  Remember that (or put it on appropriate 
RAID so you have its redundancy backing up the LVM) and LVM can certainly 
be worth the trouble of learning how it works and the initial deployment, 
yes, even on single disks.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: conversion sda to lvm2 questions

[Volker Armin Hemmann]

On Freitag, 12. Oktober 2007, Duncan wrote:

>
> Configuring mount-devices, you use /dev/sdX or /dev/srX, depending.
> (I'm not actually sure which one IDE drives use -- I run SATA drives but
> have my DVD burners on PATA still, using the libata drivers, and they
> get /dev/srX not /dev/sdX.)  Basically, try both from grub and see which
> works.  Once you figure out which devices it's using (srX or sdX), you'll
> need to setup your fstab using the correct ones.

no. just no.

The right thing, is not to mount by partition naming, but by uuid. That way it 
does not matter if the partition is called 'hda2' or 'sda2' or 'srX' or 'sgX' 
or whatever. Just mount by-uuid. It always works and it is great. Moved 
around a partition? created some before it? No problem, because you don't 
mount '/dev/hda2' you 
mount '/dev/disk/by-uuid/c1a84bd9-91f1-420e-9880-d4290599a399'
>
> Keep in mind that it's possible your device numbering will change as
> well, particularly if you already had some SATA or SCSI devices.  That's
> the most common problem people run into -- their device numbers changing
> around on them, because the kernel will load the drivers and test the
> drives in a different order than it did previously.  Another variation on
> the same problem is that devices such as thumb drives and MP3 players
> typically load as SCSI devices, so once you switch to SCSI for your
> normal drives, you may find the device numbering changing depending on
> whether your MP3player/thumb-drive is plugged in or not at boot.  One
> typical solution to this problem, if you find you have it, is using the
> other shortcuts automatically created by UDEV.  Here, I use /dev/disk/by-
> label/xxxxx for my USB drive mount-devices in fstab, thus allowing me to
> keep them straight, and access them consistently regardless of whether I
> have one or more than one plugged in at once.

and all that problems can be solved with mounting by uuid for the harddisks.

*restdeletedwithoutreading*
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] conversion sda to lvm2 questions

[Bernhard Auzinger]

Am Donnerstag 11 Oktober 2007 schrieb Beso:
> i'd like to commute my laptop system to lvm2, but before doing that i'd
> like some hints.
> first, i'd like to know if there's a way of passing an existing gentoo
> installation on a hda disk going through the sda stack (i needed to do that
> cause it was the only thing that fixed a problem with my ata disk going
> only on udma-33 after kernel 2.20) with sata-pata piix controller which is
> still experimental. i've taken a look around but haven't actually seen a
> document explaining if it is possible to do that and how to do that.
> second, i'd like to know if there's a need for a raid enabled motherboard
> and more than one disk to go on lvm. i only have a 100gb disk that i'd like
> to convert to lvm with no raid.
> and last, does it make sense doing a passage to lvm? i currently run into
> some problems with my root partition that gets filled and that i always
> have to watch the free space on it, so if i don't pass to raid i'll try to
> duplicate the partition on a greater one.
> i was forgetting: i'd like to use it on amd64. is there any problem? i have
> seen around some problems with lvm and amd64 some of them marked as solved,
> so i'd like to know if there could be problems with this arch.
> thanks for your help.

I do not have raid but I run LVM2 (on amd64) and I'm completely satisfied with 
it. I would never go back. It's just nice to be able to organize one's disk 
space in a comfortable way.

LG
Bernhard
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] conversion sda to lvm2 questions

[Daniel Gryniewicz]

On Fri, 2007-10-12 at 20:35 +0200, Bernhard Auzinger wrote:

> 
> I do not have raid but I run LVM2 (on amd64) and I'm completely satisfied with 
> it. I would never go back. It's just nice to be able to organize one's disk 
> space in a comfortable way.
> 

/metoo

Daniel

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] conversion sda to lvm2 questions

[Beso]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

so if i understood right i have to go with /boot and a stripped / on normal
disks, with / duplicated to avoid loss of startup.
on root i should put /lib32 /lib64 /etc /bin /sbin /root /dev /usr (excluded
/usr/src and /usr/local and /usr/portage) /var (i should exclude /var/tmp
which contains a lot of stuff due to ccache dir configured there and
/var/paludis since there i have the additional repos) then  on the lvm
volume i should insert everything else. am i right? i wonder what happens to
/proc and /sys since they are loaded through fstab and on how much space i
should have. do 5gb do the trick?
i don't use suspend to disk since the last time i've tried it didn't worked
with my notebook and the only suspend i can use is suspend to ram so i don't
really need swap. i use it only when i compile some large stuff as kdelibs
and similar since my 860+mb of ram do not fill in everyday use.
so the only think to do is find a good backup utility that is able to make a
copy of the entire system. if i copy the system by hand from a live-cd would
that work? if so, what should i avoid to copy?

2007/10/12, Daniel Gryniewicz <dang@gentoo.org>:
>
>
> On Fri, 2007-10-12 at 20:35 +0200, Bernhard Auzinger wrote:
>
> >
> > I do not have raid but I run LVM2 (on amd64) and I'm completely
> satisfied with
> > it. I would never go back. It's just nice to be able to organize one's
> disk
> > space in a comfortable way.
> >
>
> /metoo
>
> Daniel
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 1900 bytes --]

Re: [gentoo-amd64] conversion sda to lvm2 questions

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Beso wrote:
> so if i understood right i have to go with /boot and a stripped / on
> normal disks, with / duplicated to avoid loss of startup.

Uh - unless you don't have enough space on one drive I'd mirror root -
not stripe it.  Ditto for boot - if you are willing to do raid you can
boot a mirrored /boot just fine.

> on root i should put /lib32 /lib64 /etc /bin /sbin /root /dev /usr
> (excluded /usr/src and /usr/local and /usr/portage) /var (i should
> exclude /var/tmp which contains a lot of stuff due to ccache dir
> configured there and /var/paludis since there i have the additional
> repos) then  on the lvm volume i should insert everything else. am i
> right? 

Well, you could do that, but /usr and /var can go on LVM instead, and
that will save you a LOT of space on /.  You can then resize /usr and
/var at will.  I like to keep /var on a separate filesystem so that it
doesn't tend to fragment everything else.

> i wonder what happens to /proc and /sys since they are loaded
> through fstab and on how much space i should have. do 5gb do the trick?

/proc and /sys don't use any real disk space - they're just mountpoints.
 I have a 1GB root and it is only 30% full - but again I put usr and var
elsewhere.

> i don't use suspend to disk since the last time i've tried it didn't
> worked with my notebook and the only suspend i can use is suspend to ram
> so i don't really need swap. i use it only when i compile some large
> stuff as kdelibs and similar since my 860+mb of ram do not fill in
> everyday use.

Well, I won't start a big discussion on this here (look in the archives
for some good discussion on this topic).  The short version is that
there are potential benefits for having swap even if you have 200GB of
RAM and only run 50MB worth of applications (the returns probably do go
away if you actually have more RAM than total storage).

> so the only think to do is find a good backup utility that is able to
> make a copy of the entire system. if i copy the system by hand from a
> live-cd would that work? if so, what should i avoid to copy?
> 

You can just copy files from a live CD.  Actually, I've copied them from
a running system - granted in single-user mode for the more critical
stuff.  I just used cp -a without much issue, but there might be some
advantages to using tar (it might handle stuff like mountpoints and hard
links and device nodes and FIFOs and stuff like that better - I'm not
sure about that offhand).

If you copy and leave the original data intact it is pretty easy to
recover.  I just moved data partition by partition and remounted on my
existing root as I went along - slowly transforming my existing disk
arrangement into my future setup.  I didn't have too much downtime
except for the final cutover of the root filesystem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHEAvtG4/rWKZmVWkRAmPBAJ4vkrTg27Y8yhARb2YqtIQhwcE1OQCffrNc
oPg+UVL+KjHvGYtgVOZFeeM=
=bN8k
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-amd64] conversion sda to lvm2 questions

[Beso]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

2007/10/13, Richard Freeman <rich@thefreemanclan.net>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Beso wrote:
> > so if i understood right i have to go with /boot and a stripped / on
> > normal disks, with / duplicated to avoid loss of startup.
>
> Uh - unless you don't have enough space on one drive I'd mirror root -
> not stripe it.  Ditto for boot - if you are willing to do raid you can
> boot a mirrored /boot just fine.


can i use raid even if i got a single hd and a non raid board?! i think i
missed this thing. i knew that i could use raid on 2 separate disks of the
same ammount and only if i had a raid compatible board (with hardware or
software) but i didn't know that you could use it also on a single disk.


> > so the only think to do is find a good backup utility that is able to
> > make a copy of the entire system. if i copy the system by hand from a
> > live-cd would that work? if so, what should i avoid to copy?
> >
>
> You can just copy files from a live CD.  Actually, I've copied them from
> a running system - granted in single-user mode for the more critical
> stuff.  I just used cp -a without much issue, but there might be some
> advantages to using tar (it might handle stuff like mountpoints and hard
> links and device nodes and FIFOs and stuff like that better - I'm not
> sure about that offhand).
>
> If you copy and leave the original data intact it is pretty easy to
> recover.  I just moved data partition by partition and remounted on my
> existing root as I went along - slowly transforming my existing disk
> arrangement into my future setup.  I didn't have too much downtime
> except for the final cutover of the root filesystem.


i tried to copy the system some time ago and found out that there are files
in /dev and /tmp or /var/tmp that have an enormous dimension. i have left
them behind and then got an unusable system for some reason. the copy i had
was from a livecd with the cp -p to preserve ownership and permission.
for what i know from /dev i have only to get /dev/null and /dev/console and
let all others devices be created by udev. from /tmp instead i should not
copy anything and from /var/tmp i should copy only the ccache. are my
suppositions correct?

-----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHEAvtG4/rWKZmVWkRAmPBAJ4vkrTg27Y8yhARb2YqtIQhwcE1OQCffrNc
> oPg+UVL+KjHvGYtgVOZFeeM=
> =bN8k
> -----END PGP SIGNATURE-----
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 3300 bytes --]

Re: [gentoo-amd64] conversion sda to lvm2 questions

[Bernhard Auzinger]

Am Samstag 13 Oktober 2007 schrieb Beso:
> can i use raid even if i got a single hd and a non raid board?! i think i
> missed this thing. i knew that i could use raid on 2 separate disks of the
> same ammount and only if i had a raid compatible board (with hardware or
> software) but i didn't know that you could use it also on a single disk.

RAID = Redundant Array of Independent Disks. I think this explains that it 
would be nonsense to have raid on a single disk. 

> i tried to copy the system some time ago and found out that there are files
> in /dev and /tmp or /var/tmp that have an enormous dimension. i have left
> them behind and then got an unusable system for some reason. the copy i had
> was from a livecd with the cp -p to preserve ownership and permission.
> for what i know from /dev i have only to get /dev/null and /dev/console and
> let all others devices be created by udev. from /tmp instead i should not
> copy anything and from /var/tmp i should copy only the ccache. are my
> suppositions correct?

Of course, copying /dev/zero is not a good idea on a running system. You will 
wait forever for this task to finish (/dev/zero, remember there comes data 
out of it, endlessly).

You don't have to copy anything of /dev. udev will provide you the solution to 
create a new /dev directory after boot.

LG
Bernhard
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] conversion sda to lvm2 questions

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 3279 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Beso wrote:
>> can i use raid even if i got a single hd and a non raid board?! i think
>> i missed this thing. i knew that i could use raid on 2 separate disks of
>> the same ammount and only if i had a raid compatible board (with
>> hardware or software) but i didn't know that you could use it also on a
>> single disk.
> 

The simple answer is no - you can't use raid with one hard drive.  The
whole point of raid is to provide increased transfer rate and/or
redundancy (emphasis on the latter) by combining multiple drives together.

You do not need any special hardware to make raid work on linux (this is
software raid).  In fact, unless it is a $1000 adaptec raid controller
with battery backup that you're using I'd AVOID using any special
hardware.  My motherboard has "built-in raid support" and I don't use it
for my two raid-5 arrays or any of my raid-1s.  The cheap hardware
support provides little benefit and can cause problems (and these
solutions are almost always inflexible).

If you have only one hard drive just set up a boot partition (small), a
root partition (bigger - mine is 1GB, but you could go a little smaller
or larger), and then have one big partition assigned to lvm and then
split that up to handle everything else.

If at a later date you decide to install more hard drives and go with
raid the lvm partitions will be trivial to migrate.  Your boot will also
be easy - it isn't in use while the system is up.  The only pain will be
your root partition, and that will be mitigated by the fact that there
will be next to nothing on it.

> 
>> i tried to copy the system some time ago and found out that there are
>> files in /dev and /tmp or /var/tmp that have an enormous dimension. i
>> have left them behind and then got an unusable system for some reason.
>> the copy i had was from a livecd with the cp -p to preserve ownership
>> and permission.
>> for what i know from /dev i have only to get /dev/null and /dev/console
>> and let all others devices be created by udev. from /tmp instead i
>> should not copy anything and from /var/tmp i should copy only the
>> ccache. are my suppositions correct?
> 

If you copy files with cp - use the -a flag to make it not dereference
links/devices/etc.  "cp -a /dev/zero /tmp/zero" works just fine.

I would recommend making /tmp and /var/tmp tmpfs filesystems.  It
greatly improves performance and you shouldn't be storing anything in
these directories for longer than a reboot.  I also make myself another
tmp directory on a regular hard drive for "junk" and have tmpreaper keep
it clean - but it gets rare use.  In any case, even if you don't use
tmpfs I wouldn't bother copying them - losing your ccache isn't that big
a deal.

As somebody else pointed out, udev can take care of most of /dev, but
you do need at least a few devices there for bootup.  I don't know which
ones offhand, but you could just extract a stage 1 tarball someplace and
copy it's device directory for a core set of files.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHEOOjG4/rWKZmVWkRAlIvAJ0T4ZNKy2BovkbyzSLAigdYq3/EQQCeNygd
1HGLnNxkh6RkmWaKa7KT07g=
=Dd3P
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]