Bug#511171: lvm2: Unable to use full 3.2 TB of LVM LG on HP SmartArray E200

[teh test3s]

I think the person who originally set up the server used windows to create a
partition table so Linux could boot off of the array.  Possibly to get
around GPT partitioning?
In the RAID setup, I created two logical drives, a 200 GB drive for /boot,
/, and the MBR, and a logical drive for the remainder of the 3.5TB of
storage.

I re-installed debian, and after the install, I set up the second logical
drive as a large LVM physical volume, created a large LVM group on top of
that, and created a single large LVM logical volume on top of that.  So far,
so good.


~# pvs -v
Scanning for physical volume names
PV              VG         Fmt  Attr PSize PFree DevSize PV UUID
/dev/cciss/c0d1 bigstorevg lvm2 a-   3.22T    0    3.22T
lMjnFR-uAQ4-iBYT-rh17-egkN-q3Wi-BF0sSV


~# pvdisplay
  --- Physical volume ---
  PV Name               /dev/cciss/c0d1
  VG Name               bigstorevg
  PV Size               3.22 TB / not usable 2.93 MB
  Allocatable           yes (but full)
  PE Size (KByte)       4096
  Total PE              844215
  Free PE               0
  Allocated PE          844215


~# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "bigstorevg" using metadata type lvm2


~# lvdisplay
  --- Logical volume ---
  LV Name                /dev/bigstorevg/bigstorelv
  VG Name                bigstorevg
  LV UUID                M0A2b9-N6el-Qxsu-r8Lq-qBn2-efnM-2MsGkZ
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                3.22 TB
  Current LE             844215
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:0


~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/cciss/c0d0p3     189G  612M  179G   1% /
tmpfs                 1.8G     0  1.8G   0% /lib/init/rw
udev                   10M   88K   10M   1% /dev
tmpfs                 1.8G     0  1.8G   0% /dev/shm
/dev/cciss/c0d0p1     236M   15M  209M   7% /boot
/dev/mapper/bigstorevg-bigstorelv
                      3.2T  199M  3.1T   1% /storage



On Wed, Jan 7, 2009 at 8:43 PM, teh test3s <tehtest3s at gmail.com> wrote:

> That's a GREAT question.  The really weird thing is that the RAID array in
> question *does* actually have 3.2 TB of free space in it!  (5 x 750GB SATA
> in RAID 5 array).  I am completely baffled.
> ~# blockdev --report
> RO    RA   SSZ   BSZ   StartSec     Size    Device
> rw   256   512  4096          0  409599360  /dev/cciss/c0d0
> rw   256   512   512         63  409593177  /dev/cciss/c0d0p1
> rw   256   512  4096          0 6915815280  /dev/cciss/c0d1
> rw   256   512  1024         63     497952  /dev/cciss/c0d1p1
> rw   256   512  4096     498015    7807590  /dev/cciss/c0d1p2
> rw   256   512  1024    8305605          2  /dev/cciss/c0d1p3
> rw   256   512   512    8305668 2612532821  /dev/cciss/c0d1p5
> rw   256   512  4096          0  409591808  /dev/dm-0
>
>
> On Wed, Jan 7, 2009 at 8:35 PM, Alasdair G Kergon <agk at redhat.com> wrote:
>
>> On Wed, Jan 07, 2009 at 08:23:36PM -0500, teh test3s wrote:
>> >   PV                VG         Fmt  Attr PSize   PFree DevSize PV UUID
>> >   /dev/cciss/c0d1p5 volgroup00 lvm2 a-     3.22T 2.22T   1.22T
>> > wF9oyR-R0tf-bZeW-0es1-FhYK-f2g3-xS1Rd9
>>
>> So that's what you need to explain:
>>
>>  How come LVM thinks that device is 3.22T while it's really only 1.22T ?
>>
>> Presumably blockdev --getsize will tell you the same.
>>
>> IOW It's not an LVM issue.  Check your cciss partitioning.
>>
>> Alasdair
>> --
>> agk at redhat.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20090108/68809acf/attachment-0001.htm