Strange problem using SAM to create a new filesystem

[Dave Johnson_1]

Todd,
The truly strange bit is that I have 4 unused disks so I thought I should be able to add all 28160MB to the filesystem but I am tuck with a max of 14080MB. So if I was creating a new filesystem with 16 LUNs, I would have to allocate the space 8 times in increments of 14080MB to get to the full 112640MB. What a pain in the but. Image if I was creating a FS with 30 LUNs, or even 100 LUNs!!!!

Thanks again,
-Dave

[Todd McDaniel_1]

no points here...

I would think you could add in ANY increment that is (N x 14080)???

ie 24160, or 48320 etc...

If you just script it cut and paste your lines in vi... with Nlines/shiftY/P

[Dave Johnson_1]

Todd,
I did try all values. The current size is 28160MB which is 4 LUNs. I added 4 LUNs to the vg then tried to add the 28160MB to the lvol to get 56320MB but was only able to increase to 42240 which is 28160+14080. Then I was able to increase another 14080 to get to 56320 the full size of the vg.

I think I will open a case with HP to see if they know of some patch for LVM I might be missing or perhaps this by design (god I hope not).

Thanks,
-Dave

[Dave Johnson_1]

How did the rabbit in the hat get attached to this question. I do not recall setting it and yet there it is??

[Dave Johnson_1]

Ignore my last comments. It is because I assigned 8 points or more to one or more responses. Dah!

[Jeff Schussele]

Hi Dave,

Out of curiosity can we see
lvdisplay /dev/vg06/lvol1 ?

Also you should diskinfo EACH of those newly added 4 LUNs. I'm wondering if one of them is 14GB & the other is a "gatekeeper" LUN.
That would certainly cause the symptoms you're seeing because the striping would prevent using all four.

Rgds,
Jeff

[Dave Johnson_1]

OK,
Here is partial output:
lvdisplay -v /dev/vg06/lvol1 | head -30
--- Logical volumes ---
LV Name /dev/vg06/lvol1
VG Name /dev/vg06
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule striped
LV Size (Mbytes) 28160
Current LE 7040
Allocated PE 7040
Stripes 2
Stripe Size (Kbytes) 64
Bad block NONE
Allocation strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c5t2d0 1760 1760
/dev/dsk/c7t2d1 1760 1760
/dev/dsk/c5t2d2 1760 1760
/dev/dsk/c7t2d3 1760 1760

--- Logical extents ---
LE PV1 PE1 Status 1
00000 /dev/dsk/c5t2d0 00000 current
00001 /dev/dsk/c7t2d1 00000 current
00002 /dev/dsk/c5t2d0 00001 current
00003 /dev/dsk/c7t2d1 00001 current

Note all these LUNs come from an XP512 disk array. The process that adds them to a vg forces me to provide 2 paths to each LUN and guarantee that each LUN is exactly 7040MB in size. Each LUN can only have one SCSI ID to any given host.
Here is the diskinfo output:
for i in /dev/rdsk/c5t2d*
> do
> diskinfo $i
> done
SCSI describe of /dev/rdsk/c5t2d0:
vendor: HP
product id: OPEN-9
type: direct access
size: 7211520 Kbytes
bytes per sector: 512
SCSI describe of /dev/rdsk/c5t2d1:
vendor: HP
product id: OPEN-9
type: direct access
size: 7211520 Kbytes
bytes per sector: 512
SCSI describe of /dev/rdsk/c5t2d2:
vendor: HP
product id: OPEN-9
type: direct access
size: 7211520 Kbytes
bytes per sector: 512
SCSI describe of /dev/rdsk/c5t2d3:
vendor: HP
product id: OPEN-9
type: direct access
size: 7211520 Kbytes
bytes per sector: 512
SCSI describe of /dev/rdsk/c5t2d4:
vendor: HP
product id: OPEN-9
type: direct access
size: 7211520 Kbytes
bytes per sector: 512
SCSI describe of /dev/rdsk/c5t2d5:
vendor: HP
product id: OPEN-9
type: direct access
size: 7211520 Kbytes
bytes per sector: 512
SCSI describe of /dev/rdsk/c5t2d6:
vendor: HP
product id: OPEN-9
type: direct access
size: 7211520 Kbytes
bytes per sector: 512
SCSI describe of /dev/rdsk/c5t2d7:
vendor: HP
product id: OPEN-9
type: direct access
size: 7211520 Kbytes
bytes per sector: 512

Note: I am able to eventually get the size increased to the full 56320MB in the striped environment and all is right with the world, it just takes multiple steps to get there.

-Dave

[Jeff Schussele]

Ok - I see it in the later post now.
I believe this is normal in a 2 PV striped LV.
I think you can only add a single stripe extension at a time.
IF you had created the LV as a 4 PV stripe, then you could have added the next 4 all at once.
Not 100% positive, but I'm fairly sure.
If you think about it, you'd *want* to control this. Let's say the 4 new LUNs had 2 on c5 & 2 on c7. If LVM was choosing you may get the 1st extension on c5 & c5 & the 2nd on c7 & c7 - not optimal at all. So I'd certainly want to insure the 1st extension is c5 & c7 & the second was the same.

Rgds,
Jeff

[Dave Johnson_1]

I see where you are going with that.

It has been my experience that LVM will allocate on a FIFO basis, or if you look at the LUN list of the vg, the order they are listed, top down. Since I purposely set up the primary link to alternate between c5 and c7 then the order in the listing is how I want it.

LVM might be designed to not assume an ideal configuration and then only allow smaller allocations. Why then can I add in say 5000MB chunks? While the first few chunks are all on a pair of LUNs, eventually they will cross one pair and continue on the next pair. So LVM can allocate space from more than one pair of LUNs in a 2 stripe setup.

The more I talk to people about this, the more it seems like a bug in lvcreate/lvextend.

-Dave

[Dave Johnson_1]

More information,
I just blew away the entire vg and rebuilt it from all command line commands. When I tried to:
lvcreate -L 56320 -i 2 -I 64 /dev/vg06
I got the following:
Logical volume "/dev/vg06/lvol1" has been successfully created with
character device "/dev/vg06/rlvol1".
lvcreate: Not enough free physical extents available.
Logical volume "/dev/vg06/lvol1" could not be extended.
lvcreate: Couldn't retrieve the list of the physical volumes
belonging to volume group "/dev/vg06".
Run the "lvextend" command to create space on the Logical Volume.

Then I tried to use:
lvextend -L 56320 /dev/vg06/lvol1
and got the following:
lvextend: Not enough free physical extents available.
Logical volume "/dev/vg06/lvol1" could not be extended.
lvextend: Couldn't retrieve the list of the physical volumes
belonging to volume group "/dev/vg06".

I was then able to:
lvextend -L 14080 /dev/vg06/lvol1
lvextend -L 28160 /dev/vg06/lvol1
lvextend -L 42240 /dev/vg06/lvol1
lvextend -L 56320 /dev/vg06/lvol1
each ran with out any errors. I was then able to newfs it and mount it with out any problems.

I will be opening a case with HP about this.

Thanks to all,
-Dave