I'm confused
Hopefully, the following "summary" will make sense. ---start---
piano:/data/family# vgscan vgscan -- reading all physical volumes (this may take a while...) vgscan -- found active volume group "vg0" vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created vgscan -- WARNING: This program does not do a VGDA backup of your volume group
piano:/data/family# vgdisplay --- Volume group --- VG Name vg0 VG Access read/write VG Status available/resizable VG # 0 MAX LV 256 Cur LV 1 Open LV 1 MAX LV Size 255.99 GB Max PV 256 Cur PV 1 Act PV 1 VG Size 109.77 GB PE Size 4 MB Total PE 28102 Alloc PE / Size 109 / 436 MB Free PE / Size 27993 / 109.35 GB VG UUID hC86w2-zjFf-x2gt-1GC4-LHET-6ieO-BiC5j5
piano:/data/family# lvscan lvscan -- ACTIVE "/dev/vg0/data" [436 MB] lvscan -- 1 logical volumes with 436 MB total in 1 volume group lvscan -- 1 active logical volumes
piano:/data/family# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 1921188 672176 1151420 37% / /dev/hda1 23302 4905 17194 23% /boot /dev/vg0/data 446444 444448 1996 100% /data piano:/data/family# ---end---
I'm having trouble reconciling the 436MB of the "df" with the VG Size of vgdisplay. Obviously something is wrong somewhere. I KNOW I'm no where near using up my 120G drive yet.
For the record, this is a Debian Woody system running a 2.4.19 kernel.
Help.
Thanks
David Corbin
Once upon a time David Corbin said...
Quoted 4 lines
I'm having trouble reconciling the 436MB of the "df" with the VG Size
of vgdisplay. Obviously something is wrong somewhere. I KNOW I'm no where near using up my 120G drive yet.
Nothing is wrong. Generally you can't directly reconcile the output of df with the VG size. df output correlates to LV sizes.
Here's what you've got:
Quoted 1 line
VG Size 109.77 GB
Your volume group (vg0) is about 110GB (I gather the other 10GB of your drive is allocated to other partitions).
Quoted 1 line
Alloc PE / Size 109 / 436 MB
You've used up (allocated) 436MB of the volume group
Quoted 1 line
Free PE / Size 27993 / 109.35 GB
You have still almost 110GB free (since you allocated only 436MB)
Quoted 1 line
lvscan -- ACTIVE "
/dev/vg0/data" [436 MB]
Your data partition is the only LV and that is using the 436MB used in vg0.
Quoted 1 line
/dev/vg0/data446444 444448 1996 100% /data
Your filesystem on /dev/vg0/data is using the entire 436MB of the partition. And its full.
What you need to do now is extend your logical volume to allocate more space to it. Then resize the filesystem. If you have an ext2/ext3 filesystem, you use "e2fsadm --size ...". If you have xfs, you use "xfs_growfs ...". I dont know about other filesystem types.
eg. to add 10G to your data partition (assuming xfs - that's what I use):
# lvextend --size +10G /dev/vg0/data # xfs_growfs /dev/vg0/data
df(1) should now show a large filesystem with much more space.
Quoted 10 lines
Quoted 5 lines
VG Size 109.77 GB
Your volume group (vg0) is about 110GB (I gather the other 10GB of your drive is allocated to other partitions).
Well, About 3 gig is other partions, and it appears to me that the other 7G is lost to making the raid device and various overheads (though that sure seems excessive).
Quoted 27 lines
Quoted 5 lines
Alloc PE / Size 109 / 436 MB
You've used up (allocated) 436MB of the volume group
Quoted 3 lines
Free PE / Size 27993 / 109.35 GB
You have still almost 110GB free (since you allocated only 436MB)
Quoted 3 lines
lvscan -- ACTIVE "
/dev/vg0/data" [436 MB]Your data partition is the only LV and that is using the 436MB used in vg0.
Quoted 9 lines
Quoted 3 lines
/dev/vg0/data446444 444448 1996 100% /dataYour filesystem on
/dev/vg0/datais using the entire 436MB of the partition. And its full.
The odd thing is that I'm sure I created the LV at a full 100% of the disk...
Quoted 5 lines
What you need to do now is extend your logical volume to allocate more space to it. Then resize the filesystem. If you have an ext2/ext3 filesystem, you use "e2fsadm --size ...". If you have xfs, you use "
xfs_growfs...". I dont know about other filesystem types.
Quoted 7 lines
eg. to add 10G to your data partition (assuming xfs - that's what I use):
# lvextend --size +10G /dev/vg0/data # xfs_growfs /dev/vg0/datadf(1) should now show a large filesystem with much more space.
I did as you suggested, and used "resize_reiserfs". It seems better, but we shall see if it changes on me again...
On Sunday 08 December 2002 12:25, David Corbin wrote:
[snip]
Quoted 4 lines
Well, About 3 gig is other partions, and it appears to me that the other 7G is lost to making the raid device and various overheads (though that sure seems excessive).
I think hardisk manufacturers use base 10, rather than base 2, when they speak of "mega" and "giga", ie. mega = 1000K and not 1024K. That means that a 120G hardisk is only 114.4G. Hence, 109.77G + about 3G = about 113G. Hmm, still about 1.5G missing.
-- Pantaleimon <[email protected]>
Quoted 9 lines · David Corbin
[snip]
Quoted 4 lines
Well, About 3 gig is other partions, and it appears to me that the other 7G is lost to making the raid device and various overheads (though that sure seems excessive).
Quoted 4 lines
I think hardisk manufacturers use base 10, rather than base 2, when they speak of "mega" and "giga", ie. mega = 1000K and not 1024K. That means that a 120G hardisk is only 114.4G. Hence, 109.77G + about 3G = about 113G. Hmm, still about 1.5G missing.
They also quote the size before laying down timing tracks and bad block mappings -- along with the bad blocks. That accounts for another 10%.
Drives look kind of like modern lumber: you have to ignore the nominal size in your calculations and deal with finished size in order to plan for anything -- or just accept that 10% "shrinkage" is a normal part of life.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
Quoted 8 lines
Quoted 4 lines
I think hardisk manufacturers use base 10, rather than base 2, when they speak of "mega" and "giga", ie. mega = 1000K and not 1024K. That means that a 120G hardisk is only 114.4G. Hence, 109.77G + about 3G = about 113G. Hmm, still about 1.5G missing.
They also quote the size before laying down timing tracks and bad block mappings -- along with the bad blocks. That accounts for another 10%.
What you are saying is completely wrong.
When a drive manufacturer quotes a drive with a capacity of 100 GB, what they are quoting is the *user* capacity.
There are at least 100 GB available to the "user".
The "user" is the host machine.
For a typical 512 byte block size that will mean that there will be at least:
100 x 10^9 / 512 blocks
195 312 500 blocks
available to the *user*, i.e. the host machine.
Whatever the drive uses internally is not counted.
If you look at drive specs, you will sometimes see a figure quoted for "user data sectors" (in this case 195 312 500) and this always indicates a capacity higher than the quoted drive capacity.
Bill
Signature · 17 lines
William H. Blunn - <[email protected]> - Developer Support Tao 62/63 Suttons Business Park, Earley, READING, RG6 1AZ, United Kingdom Tel: +44 118 901 2999 - Fax: +44 118 901 2963 - http://tao-group.com/ The contents of this e-mail and any attachments are confidential and may be legally privileged. If you have received this e-mail and you are not a named addressee, please inform us as soon as possible on +44 118 901 2999 and then delete the e-mail from your system. If you are not a named addressee you must not copy, use, disclose, distribute, print or rely on this e-mail. Any views expressed in this e-mail or any attachments may not necessarily reflect those of Tao's management. Although we routinely screen for viruses, addressees should scan this e-mail and any attachments for viruses. Tao makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that for the protection of our business, we may monitor and read e-mails sent to and from our server(s).
Quoted 3 lines
I think hardisk manufacturers use base 10, rather than base 2, when they speak of "mega" and "giga", ie. mega = 1000K and not 1024K. That means that a 120G hardisk is only 114.4G.
No.
You are right in that "mega = 1000K", but from your figure of 114.4, you still appear to have "K = 1024" and "G = 1024M", both of which are wrong.
Hard disk manufacturers use SI defined multipliers, i.e. they use a documented standard.
K = 10^3
M = 10^6
G = 10^9
120 GB = 120 000 000 000 B
Computer people have traditionally abused these symbols to mean multipliers with similar values, but based on powers of two.
Symbols have been defined for these multipliers, but some people still haven't caught up to them.
Ki = 2^10 = 1024
Mi = 2^20 = 1048576
Gi = 2^30 = 1073741824
So
120 GB ~= 111.8 GiB
Interestingly, LVM1's vgdisplay incorrectly uses "GB" in its output where it should say "GiB".
Bill
Signature · 17 lines
William H. Blunn - <[email protected]> - Developer Support Tao 62/63 Suttons Business Park, Earley, READING, RG6 1AZ, United Kingdom Tel: +44 118 901 2999 - Fax: +44 118 901 2963 - http://tao-group.com/ The contents of this e-mail and any attachments are confidential and may be legally privileged. If you have received this e-mail and you are not a named addressee, please inform us as soon as possible on +44 118 901 2999 and then delete the e-mail from your system. If you are not a named addressee you must not copy, use, disclose, distribute, print or rely on this e-mail. Any views expressed in this e-mail or any attachments may not necessarily reflect those of Tao's management. Although we routinely screen for viruses, addressees should scan this e-mail and any attachments for viruses. Tao makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that for the protection of our business, we may monitor and read e-mails sent to and from our server(s).
Quoted 10 lines · William Blunn
Quoted 3 lines
I think hardisk manufacturers use base 10, rather than base 2, when they speak of "mega" and "giga", ie. mega = 1000K and not 1024K. That means that a 120G hardisk is only 114.4G.
No.
You are right in that "mega = 1000K", but from your figure of 114.4, you still appear to have "K = 1024" and "G = 1024M", both of which are wrong.
I had G=1000, M=1000 and K=1024 which would give 120 x 10^6 x 1024 =114.4KiB. I stand corrected on the matter of me saying/implying K=1024.
I am glad to hear that symbols have been defined for the base 2 multipliers. I shall try to use them. I seem to remember reading somthing about it sometime ago. Didn't someone propose to use something like KK, MM and GG, too. When I tell some people that, even when it comes to computers, the multiplier "kilo" formally, if not in practice, means "x 1000" they just won't believe me.
Quoted 27 lines
Hard disk manufacturers use SI defined multipliers, i.e. they use a documented standard.
K = 10^3
M = 10^6
G = 10^9120 GB = 120 000 000 000 B
Computer people have traditionally abused these symbols to mean multipliers with similar values, but based on powers of two.
Symbols have been defined for these multipliers, but some people still haven't caught up to them.
Ki = 2^10 = 1024
Mi = 2^20 = 1048576
Gi = 2^30 = 1073741824So
120 GB ~= 111.8 GiB
Interestingly, LVM1's vgdisplay incorrectly uses "GB" in its output where it should say "GiB".
Bill