expanding physical disks
How does LVM deal with physical disks that can get bigger or smaller, such as a hardware RAID device? What happens to a PV on a hardware RAID-5 device that is presented to the system as a single (say scsci) target when you put a few more disks in it and tell the hardware raid device to add them to the given (scsi) target that a PV was created on? (what a mouthful).
Is this really possible or can one only expand a hardware raid array for LVM usage by adding additional raid targets and then adding the raid targets as PVs to a VG?
b.
Quoted 6 lines · Brian Murrell
How does LVM deal with physical disks that can get bigger or smaller, such as a hardware RAID device? What happens to a PV on a hardware RAID-5 device that is presented to the system as a single (say scsci) target when you put a few more disks in it and tell the hardware raid device to add them to the given (scsi) target that a PV was created on? (what a mouthful).
Doesn't work at this time. LVM will only see what was originally there at the time pvcreate was run (or possibly vgcreate/vgextend).
It would not be impossible to fix this, however, depending on your needs. The way the VGDA is layed out is as follows:
PV data
VG data
PV UUID list
LV data
PE map
(padding = original PV size % PE size (usually))
PE 0 = start of user data
When you increase the size of the PV itself, you are essentially adding PEs to the end that need to be added to the PE map. It is possible that the PEs will fit into the padding space. If that is the case, you don't have many problems, and you are happy, assuming you know enough about LVM user tools and metadata layout to write a tool to do this.
If the new PEs don't all fit into the padding space (it may happen if your starting PV size is just a couple hundred kB over n * PE size), then you will need to pvmove PE0 from its current location to somewhere else in the VG, and then renumber all of the PEs on that PV as (PE# - 1). That couble be ugly because I believe the PE number is stored in the snapshot tables and such.
Probably not worth the effort. Since each PE map entry is only 4 bytes in size at this time, and you will normally have at least 4MB PEs, on average you will be able to grow to 2MB/4*4MB=2TB (max ~4TB) without any need for the complexity of the second option. With 8MB PEs, you get on average 8TB (max ~16TB).
The simple answer is don't do that. If you write a tool to handle the first case, then all you need to do is make the PE size sufficiently large that you will "always" have enough padding to extend the PV to any practical size. You can easily hack the LVM code to ensure that the pe_on_disk.size is always large enough to add an arbitrary number of PEs, just by subtracting one or more PEs from the usable space at the time it is initially set up.
Quoted 3 lines
Is this really possible or can one only expand a hardware raid array for LVM usage by adding additional raid targets and then adding the raid targets as PVs to a VG?
This is the only currently available way to do it, the speculation above notwithstanding. Another solution (if you have the disk space) is to pvmove all of the PEs from the PV you want to expand, vgreduce the PV from the VG, extend the PV to the new size, pvcreate it again, and then vgextend the VG with the "new" PV. This requires 2xPV size whenever you need to extend the PV, which is kind of counter productive.
Cheers, Andreas
Signature · 3 lines
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- DogbertQuoted 10 lines · Andreas Dilger
Quoted 6 lines · Brian Murrell
How does LVM deal with physical disks that can get bigger or smaller, such as a hardware RAID device? What happens to a PV on a hardware RAID-5 device that is presented to the system as a single (say scsci) target when you put a few more disks in it and tell the hardware raid device to add them to the given (scsi) target that a PV was created on? (what a mouthful).
Doesn't work at this time. LVM will only see what was originally there at the time pvcreate was run (or possibly vgcreate/vgextend).
At the moment your only chance is to create partitions on it and use those partitions as PVs
L.
Signature · 6 lines
Luca Berra -- [email protected] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \
Quoted 9 lines · Luca Berra
Quoted 8 lines · Andreas Dilger
Quoted 6 lines · Brian Murrell
How does LVM deal with physical disks that can get bigger or smaller, such as a hardware RAID device? What happens to a PV on a hardware RAID-5 device that is presented to the system as a single (say scsci) target when you put a few more disks in it and tell the hardware raid device to add them to the given (scsi) target that a PV was created on? (what a mouthful).
Quoted 5 lines
Quoted 2 lines
Doesn't work at this time. LVM will only see what was originally there at the time pvcreate was run (or possibly vgcreate/vgextend).
At the moment your only chance is to create partitions on it and use those partitions as PVs
Just a thought, a bit off topic perhaps.
If you're using LVM primarily as a way to make it possible for you to expand your storage space on-line (and on-mount-point) wouldn't it be "easier" to _just_ use the RAID? i.e. expand the RAID volume on the controller, so basically the "disk" is bigger now, and the just "grow" your partition, extend your filesystem, and that's it?
It's a thought I've been toying with since seeing the IBM ServeRAID's capability to grow volumes. I've not attempted any testing though, so this is pure speculation...
(PS: All this means nothing if you're using LVM for it's other features, like striping, but then the RAID can do that too...)
Signature · 6 lines
"You show me an American who can keep his mouth shut and I'll eat him." -- Newspaperman from Frank Capra's _Meet_John_Doe_ --------------------------------------------------------------------------- Hugo Lombard Infoline (Pty) Ltd System Administrator ---------------------------------------------------------------------------
Quoted 10 lines · Hugo Lombard
Quoted 9 lines · Luca Berra
Quoted 8 lines · Andreas Dilger
Quoted 6 lines · Brian Murrell
How does LVM deal with physical disks that can get bigger or smaller, such as a hardware RAID device? What happens to a PV on a hardware RAID-5 device that is presented to the system as a single (say scsci) target when you put a few more disks in it and tell the hardware raid device to add them to the given (scsi) target that a PV was created on? (what a mouthful).
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Doesn't work at this time. LVM will only see what was originally there at the time pvcreate was run (or possibly vgcreate/vgextend).
At the moment your only chance is to create partitions on it and use those partitions as PVs
Just a thought, a bit off topic perhaps.
;-)
Quoted 6 lines
If you're using LVM primarily as a way to make it possible for you to expand your storage space on-line (and on-mount-point) wouldn't it be "easier" to _just_ use the RAID? i.e. expand the RAID volume on the controller, so basically the "disk" is bigger now, and the just "grow" your partition, extend your filesystem, and that's it?
I think you're right in case you can live with the restrictions involved.
If the amount of resizable volumes a single smart controller can support is enough, you can surely go with that solution. When it comes to more storage you need a logical volume manager to group multiple disk subsystems together in order to support large storage configurations.
Quoted 7 lines
It's a thought I've been toying with since seeing the IBM ServeRAID's capability to grow volumes. I've not attempted any testing though, so this is pure speculation...
(PS: All this means nothing if you're using LVM for it's other features, like striping, but then the RAID can do that too...)
Plus LVM's features to move data around online in order to relocate it to faster/bigger/newer disk subsystems, to have more that just a couple of resizable devices, support for hardware block device reconfiguration without any changes in the namespace of the logical volumes, snapshot support etc.
Regards,
Heinz -- The LVM Guy --
Quoted 16 lines
Signature · 12 lines
-- "You show me an American who can keep his mouth shut and I'll eat him." -- Newspaperman from Frank Capra's _Meet_John_Doe_ --------------------------------------------------------------------------- Hugo Lombard Infoline (Pty) Ltd System Administrator --------------------------------------------------------------------------- _______________________________________________ linux-lvm mailing list [email protected] http://lists.sistina.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Quoted 10 lines · Heinz J. Mauelshagen
Quoted 6 lines · Hugo Lombard
If you're using LVM primarily as a way to make it possible for you to expand your storage space on-line (and on-mount-point) wouldn't it be "easier" to _just_ use the RAID? i.e. expand the RAID volume on the controller, so basically the "disk" is bigger now, and the just "grow" your partition, extend your filesystem, and that's it?
I think you're right in case you can live with the restrictions involved.
I'm right!?!?! Mother would be so proud!! ;)
Quoted 5 lines
If the amount of resizable volumes a single smart controller can support is enough, you can surely go with that solution. When it comes to more storage you need a logical volume manager to group multiple disk subsystems together in order to support large storage configurations.
*nod* As usual, there's no universal answer, and it depends on you needs/configuration/preference/phase of moon...
Quoted 5 lines
Quoted 5 lines
It's a thought I've been toying with since seeing the IBM ServeRAID's capability to grow volumes. I've not attempted any testing though, so this is pure speculation...
Quoted 8 lines
Quoted 2 lines
(PS: All this means nothing if you're using LVM for it's other features, like striping, but then the RAID can do that too...)
Plus LVM's features to move data around online in order to relocate it to faster/bigger/newer disk subsystems, to have more that just a couple of resizable devices, support for hardware block device reconfiguration without any changes in the namespace of the logical volumes, snapshot support etc.
Very important features to consider, for sure.
Signature · 8 lines
Dorothy: But how can you talk without a brain? Scarecrow: Well, I don't know... but some people without brains do an awful lot of talking. -- The Wizard of Oz --------------------------------------------------------------------------- Hugo Lombard Infoline (Pty) Ltd System Administrator ---------------------------------------------------------------------------
Quoted 6 lines · Andreas Dilger
Quoted 2 lines · Brian Murrell
How does LVM deal with physical disks that can get bigger or smaller, such as a hardware RAID device?
Doesn't work at this time. LVM will only see what was originally there at the time pvcreate was run (or possibly vgcreate/vgextend).
But it won't do any harm either, right?
Quoted 6 lines
If the new PEs don't all fit into the padding space (it may happen if your starting PV size is just a couple hundred kB over n * PE size), then you will need to pvmove PE0 from its current location to somewhere else in the VG, and then renumber all of the PEs on that PV as (PE# - 1). That couble be ugly because I believe the PE number is stored in the snapshot tables and such.
Since this is a case of making the PV bigger, all the PEs could simply be shifted by one; there is, after all, more room at the end now. That would still be ugly, though.
paul
Quoted 17 lines · Paul Jarc
Quoted 6 lines · Andreas Dilger
Quoted 2 lines · Brian Murrell
How does LVM deal with physical disks that can get bigger or smaller, such as a hardware RAID device?
Doesn't work at this time. LVM will only see what was originally there at the time pvcreate was run (or possibly vgcreate/vgextend).
But it won't do any harm either, right?
Quoted 6 lines
If the new PEs don't all fit into the padding space (it may happen if your starting PV size is just a couple hundred kB over n * PE size), then you will need to pvmove PE0 from its current location to somewhere else in the VG, and then renumber all of the PEs on that PV as (PE# - 1). That couble be ugly because I believe the PE number is stored in the snapshot tables and such.
Quoted 3 lines
Since this is a case of making the PV bigger, all the PEs could simply be shifted by one; there is, after all, more room at the end now. That would still be ugly, though.
Yes, it would :-(
Typical HW storage subsystems anable you to create additional IDs (for eg. SCSI LUNs) to addrees the gained storage once you insert additional drives.
Do you have constraints to create those and just use the as new PVs or is the maximum of 8 LUNs in the SCSI case insufficient for you?
That's the way we did it quite happily for multiple years in my previous job on HP, SUN and other platforms :-)
Quoted 8 lines
paul
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
Signature · 15 lines
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-