Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
lvm question
16 views
Skip to first unread message
rvae...@gmail.com
Jul 30, 2012, 2:35:24 PM7/30/12
to
I have already a file system set up on a server like this:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/Vol-root
9.7G 2.8G 6.5G 31% /
/dev/mapper/Vol-varlv
3.9G 691M 3.1G 19% /var
/dev/mapper/Vol-tmplv
3.9G 137M 3.6G 4% /tmp
/dev/mapper/Vol-optlv
13G 9.9G 1.9G 85% /opt
/dev/mapper/Vol-homelv
992M 34M 908M 4% /home
/dev/vda1 487M 31M 431M 7% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
I wanted to mount /usr using LVM. /usr is already taken by another volume group. I wanted to add another volume-group.
Any suggestions?
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/Vol-root
9.7G 2.8G 6.5G 31% /
/dev/mapper/Vol-varlv
3.9G 691M 3.1G 19% /var
/dev/mapper/Vol-tmplv
3.9G 137M 3.6G 4% /tmp
/dev/mapper/Vol-optlv
13G 9.9G 1.9G 85% /opt
/dev/mapper/Vol-homelv
992M 34M 908M 4% /home
/dev/vda1 487M 31M 431M 7% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
I wanted to mount /usr using LVM. /usr is already taken by another volume group. I wanted to add another volume-group.
Any suggestions?
kcGSH6nC
Jul 30, 2012, 8:48:38 PM7/30/12
to
to me like it's just sitting in / as a normal directory, unless that's
waht you meant.
1. Drop to runlevel 1.
2. Prepare the destination storage (look up LVM to find the commands for
that part)
3. Mount the new volume somewhere (but NOT /usr)
4. *** cd /usr; cp -rav . /somewhere/else ***
5. Unmount the new volume
6. Mount the new volume to /usr as appropriate
7. Look around and make sure everything is kosher
8. Unmount /usr again
9. Delete contents of /usr to recover space, since you checked at #7 the
data was moved correctly. If you screw this up and don't have backups,
it's not my fault ;)
10. Update /etc/fstab as appropriate
11. Reboot or jump to the desired runlevel and all should be good.
*** This may need adjustment. just make sure you're copying everything -
data, ownership, attributes, permissions, contexts (if selinux) etc.
Aragorn
Jul 31, 2012, 7:20:47 AM7/31/12
to
On Tuesday 31 July 2012 02:48, kcGSH6nC conveyed the following to
alt.os.linux...
In addition to all of that, there's no guarantee anymore that his system
would still work with a separate /usr filesystem due to certain
decisions made at RedHat, where both udev and systemd are developed.
There are workarounds, but those could be tricky for inexperienced
users, because they include adding a script to the initramfs, which then
mounts /usr before udev is started. udev now relies on stuff under
/usr, and so does systemd, and the most recent versions of both even
install themselves under /usr, so you need /usr mounted at boot - Fedora
for instance already follows that convention.
Not knowing what distribution the OP is running, in my personal opinion,
it would be saner for the OP if he were to first and foremost get rid of
the logical volume for /tmp and have the contents of /tmp reside on a
tmpfs instead.
--
= Aragorn =
(registered GNU/Linux user #223157)
alt.os.linux...
would still work with a separate /usr filesystem due to certain
decisions made at RedHat, where both udev and systemd are developed.
There are workarounds, but those could be tricky for inexperienced
users, because they include adding a script to the initramfs, which then
mounts /usr before udev is started. udev now relies on stuff under
/usr, and so does systemd, and the most recent versions of both even
install themselves under /usr, so you need /usr mounted at boot - Fedora
for instance already follows that convention.
Not knowing what distribution the OP is running, in my personal opinion,
it would be saner for the OP if he were to first and foremost get rid of
the logical volume for /tmp and have the contents of /tmp reside on a
tmpfs instead.
--
= Aragorn =
(registered GNU/Linux user #223157)
rvae...@gmail.com
Jul 31, 2012, 10:38:29 AM7/31/12
to
Disk /dev/vdb: 214.7 GB, 214748364800 bytes
255 heads, 63 sectors/track, 26108 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/vdb1 * 1 1020 8193118+ 82 Linux swap / Solaris
/dev/vdb2 1021 26108 201519360 8e Linux LVM
rvae...@gmail.com
Jul 31, 2012, 10:35:44 AM7/31/12
to
On Monday, July 30, 2012 2:35:24 PM UTC-4, (unknown) wrote:
On Monday, July 30, 2012 2:35:24 PM UTC-4, (unknown) wrote:
On Monday, July 30, 2012 2:35:24 PM UTC-4, (unknown) wrote:
On Monday, July 30, 2012 2:35:24 PM UTC-4, (unknown) wrote:
J.O. Aho
Jul 31, 2012, 1:29:08 PM7/31/12
to
Total PE 49210
Alloc PE / Size 35824 / 2.19 TiB
Free PE / Size 13386 / 836.62 GiB
If the Free PE is 0, then you need to free space from somewhere else.
I suggest you look at the result from df
df -h | grep Vol
Look for the ones with the most free space (the value infront of the per cent
value),
/dev/mapper/Vol-homelv 30G 2.1G 28G 7% /home
/dev/mapper/Vol-tmplv 350G 141G 210G 41% /tmp
in this example it would be best to shrink the Vol-tmplv
how to do this: http://tldp.org/HOWTO/LVM-HOWTO/reducelv.html
as you notice, you can't shrink xfs and jfs, so if you are using one of those,
you are in bad luck. For ext3 adn ext4 it's similar to how done with ext2.
If you don't have enough space to take from the other logical volumes, then
your only option is to buy more disk space for your VM.
As Aragon already pointed out, there is a big risk you end up in trouble if
you make a different logical volume for /usr, it would be a lot simpler for
you to just let / grow.
See http://tldp.org/HOWTO/LVM-HOWTO/extendlv.html
--
//Aho
rvae...@gmail.com
Jul 31, 2012, 7:26:32 PM7/31/12
to
Thank you for all your support
On Monday, July 30, 2012 2:35:24 PM UTC-4, (unknown) wrote:
Jasen Betts
Aug 2, 2012, 8:52:02 AM8/2/12
to
On 2012-07-31, Aragorn <str...@telenet.be.invalid> wrote:
>
> Not knowing what distribution the OP is running, in my personal opinion,
> it would be saner for the OP if he were to first and foremost get rid of
> the logical volume for /tmp and have the contents of /tmp reside on a
> tmpfs instead.
if you do that, how do you avoid the problem of needing too much swap
>
> Not knowing what distribution the OP is running, in my personal opinion,
> it would be saner for the OP if he were to first and foremost get rid of
> the logical volume for /tmp and have the contents of /tmp reside on a
> tmpfs instead.
or not having enough tmp?
--
⚂⚃ 100% natural
--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---
Aragorn
Aug 2, 2012, 10:51:34 AM8/2/12
to
On Thursday 02 August 2012 14:52, Jasen Betts conveyed the following to
alt.os.linux...
> On 2012-07-31, Aragorn <str...@telenet.be.invalid> wrote:
>
>> Not knowing what distribution the OP is running, in my personal
>> opinion, it would be saner for the OP if he were to first and
>> foremost get rid of the logical volume for /tmp and have the contents
>> of /tmp reside on a tmpfs instead.
>
> if you do that, how do you avoid the problem of needing too much swap
> or not having enough tmp?
/tmp should be kept small either way. User accounts normally have a
~/tmp directory which should be used for their own temporary files -
e.g. while downloading, etc.
The systemwide /tmp is intended for things like sockets, and nothing
residing there should be expected to survive reboots. (Stuff of a
similar nature which needs more persistent storage should go under
/var/tmp.)
alt.os.linux...
> On 2012-07-31, Aragorn <str...@telenet.be.invalid> wrote:
>
>> Not knowing what distribution the OP is running, in my personal
>> opinion, it would be saner for the OP if he were to first and
>> foremost get rid of the logical volume for /tmp and have the contents
>> of /tmp reside on a tmpfs instead.
>
> if you do that, how do you avoid the problem of needing too much swap
> or not having enough tmp?
~/tmp directory which should be used for their own temporary files -
e.g. while downloading, etc.
The systemwide /tmp is intended for things like sockets, and nothing
residing there should be expected to survive reboots. (Stuff of a
similar nature which needs more persistent storage should go under
/var/tmp.)
Richard Kettlewell
Aug 2, 2012, 12:01:08 PM8/2/12
to
/tmp.
--
http://www.greenend.org.uk/rjk/
kcGSH6nC
Aug 2, 2012, 8:32:07 PM8/2/12
to
it, it gets it (and the contents of the tmpfs get swapped out).
Ohmster
Aug 4, 2012, 2:35:52 AM8/4/12
to
Aragorn <str...@telenet.be.invalid> wrote in news:jv8f2f$el8$1@dont-
email.me:
> Not knowing what distribution the OP is running, in my personal opinion,
> it would be saner for the OP if he were to first and foremost get rid of
> the logical volume for /tmp and have the contents of /tmp reside on a
> tmpfs instead.
I cannot get involved in this situation, my experience with LVM was sort of
"forced on me", being stupid and hosing my own system, took me ten days to
figure out how to fix it again, and I was only able to do that because I
used dd to copy the disk headers to a file before they got pushed out of
the disk buffer.
I really wanted to chime in and say that is pretty good advice, Aragorn.
You have been at the help desk for a long time and your advice is
considered, at least by me, to be "top shelf". Good one.
--
~Ohmster | ohmster59 /a/t/ gmail dot com
email.me:
> Not knowing what distribution the OP is running, in my personal opinion,
> it would be saner for the OP if he were to first and foremost get rid of
> the logical volume for /tmp and have the contents of /tmp reside on a
> tmpfs instead.
"forced on me", being stupid and hosing my own system, took me ten days to
figure out how to fix it again, and I was only able to do that because I
used dd to copy the disk headers to a file before they got pushed out of
the disk buffer.
I really wanted to chime in and say that is pretty good advice, Aragorn.
You have been at the help desk for a long time and your advice is
considered, at least by me, to be "top shelf". Good one.
--
~Ohmster | ohmster59 /a/t/ gmail dot com
0 new messages