From: Marcus Claesson <m.claesson@student.ucc.ie>
To: linux-lvm@redhat.com
Subject: [linux-lvm] Why didn't the lv extension go through even if lvdisplay says so?
Date: Tue, 16 May 2006 13:18:41 +0100 [thread overview]
Message-ID: <1147781921.24056.64.camel@morpheus.ucc.ie> (raw)
Hi all,
I want to allocate 140G of the free space in my VG and use it to
extend /var (/dev/Volume00/LogVol01) from 97G to 240G. After I
unmounted /var (which was impossible until I used a lazy 'umount -
l /var'), I ran
# lvextend -L 240G /dev/Volume00/LogVol01
(unfortunately I was in single-user mode and wasn't able to save the
output, but it basically said 'extension successful). I then re-
mounted /var:
# mount /dev/mapper/Volume00-LogVol01 /var/
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
and ran a df to check:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/cciss/c0d0p2 49G 19G 27G 42% /
/dev/cciss/c0d0p1 99M 9.8M 84M 11% /boot
/dev/mapper/Volume00-LogVol00
97G 84G 8.1G 92% /home
none 2.9G 0 2.9G 0% /dev/shm
/dev/mapper/Volume00-LogVol02
20G 11G 8.4G 56% /usr/local
sunrpc 97G 88G 3.6G 97% /var/lib/nfs/rpc_pipefs
/dev/mapper/Volume00-LogVol01
97G 88G 3.6G 97% /var
To my surprise /var hadn't been extended at all and a new sunrpc device
had also been mounted! The lvm info is now:
# vgdisplay
--- Volume group ---
VG Name Volume00
System ID localhost.localdomain1077884666
Format lvm1
VG Access read/write
VG Status resizable
MAX LV 256
Cur LV 3
Open LV 3
Max PV 256
Cur PV 1
Act PV 1
VG Size 496.02 GB
PE Size 4.00 MB
Total PE 126981
Alloc PE / Size 91560 / 357.66 GB
Free PE / Size 35421 / 138.36 GB
VG UUID H0hRDH-Ud2L-fYSG-j1mE-3QfB-5xMo-3Sb6Mf
Thus 240G has been used up.
# lvdisplay
--- Logical volume ---
LV Name /dev/Volume00/LogVol01
VG Name Volume00
LV UUID 000000-0000-0000-0000-0000-0000-000002
LV Write Access read/write
LV Status available
# open 1
LV Size 240.00 GB
Current LE 61440
Segments 1
Allocation normal
Read ahead sectors 10000
Block device 253:2
Thus new size as it should be.
Also, the difference between the current and old VG is:
# diff /etc/lvm/backup/Volume00 /etc/lvm/archive/Volume00_00004.vg
1c1
< # Generated by LVM2: Tue May 16 12:27:42 2006
---
> # Generated by LVM2: Tue May 16 12:24:15 2006
6c6
< description = "Created *after* executing 'vgdisplay'"
---
> description = "Created *before* executing 'lvextend -L 240G -
v /dev/Volume00/LogVol01'"
9c9
< creation_time = 1147778862 # Tue May 16 12:27:42 2006
---
> creation_time = 1147778655 # Tue May 16 12:24:15 2006
83c83
< extent_count = 61440 # 240 Gigabytes
---
> extent_count = 25000 # 97.6562
Gigabytes
The whole new /etc/lvm/backup/Volume00 is
# cat /etc/lvm/backup/Volume00
# Generated by LVM2: Tue May 16 12:27:42 2006
contents = "Text Format Volume Group"
version = 1
description = "Created *after* executing 'vgdisplay'"
creation_host = "neo.ucc.ie" # Linux neo.ucc.ie 2.6.9-34.ELsmp #1 SMP
Fri Feb 24 16:54:53 EST 2006 i686
creation_time = 1147778862 # Tue May 16 12:27:42 2006
Volume00 {
id = "H0hRDH-Ud2L-fYSG-j1mE-3QfB-5xMo-3Sb6Mf"
seqno = 0
status = ["RESIZEABLE", "READ", "WRITE"]
system_id = "localhost.localdomain1077884666"
extent_size = 8192 # 4 Megabytes
max_lv = 256
max_pv = 256
physical_volumes {
pv0 {
id = "xXbxiu-uog2-xSRe-dI2z-y2ZQ-9weE-ftY6YL"
device = "/dev/cciss/c0d0p5" # Hint only
status = ["ALLOCATABLE"]
pe_start = 9472
pe_count = 126981 # 496.02 Gigabytes
}
}
logical_volumes {
LogVol00 {
id = "000000-0000-0000-0000-0000-0000-000000"
status = ["READ", "WRITE", "VISIBLE"]
allocation_policy = "normal"
read_ahead = 10000
segment_count = 1
segment1 {
start_extent = 0
extent_count = 25000 # 97.6562
Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
LogVol02 {
id = "000000-0000-0000-0000-0000-0000-000001"
status = ["READ", "WRITE", "VISIBLE"]
allocation_policy = "normal"
read_ahead = 10000
segment_count = 1
segment1 {
start_extent = 0
extent_count = 5120 # 20 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 25000
]
}
}
LogVol01 {
id = "000000-0000-0000-0000-0000-0000-000002"
status = ["READ", "WRITE", "VISIBLE"]
allocation_policy = "normal"
read_ahead = 10000
segment_count = 1
segment1 {
start_extent = 0
extent_count = 61440 # 240 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 50000
]
}
}
}
}
How come the size extension didn't go through?
Any hints are much appreciated!
Regards,
Marcus
next reply other threads:[~2006-05-16 12:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-16 12:18 Marcus Claesson [this message]
2006-05-16 12:32 ` [linux-lvm] Why didn't the lv extension go through even if lvdisplay says so? Patrick Caulfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1147781921.24056.64.camel@morpheus.ucc.ie \
--to=m.claesson@student.ucc.ie \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).