When I try to create an LVM2 container on the raid0 region the 2.4.1 CLI
Region Name: md/md0
Region Size: 3.18 TB
Region Type: Data
The log with 'everything' had:
Dec 05 09:52:12 beast _6_ LVM2: create_container_set_objects: Maximum allowed extent size is 4294967296.
Dec 05 09:52:12 beast _9_ Engine: engine_free: Enter.
Dec 05 09:52:12 beast _9_ Engine: engine_free: Request to free memory at (nil).
Dec 05 09:52:12 beast _9_ Engine: engine_free: Exit.
Dec 05 09:52:12 beast _9_ Engine: engine_alloc: Enter.
Dec 05 09:52:12 beast _9_ Engine: engine_alloc: Request to allocate 4294967276 (0xffffffec) bytes.
Dec 05 09:52:12 beast _9_ Engine: engine_alloc: Exit. Returned pointer is (nil).
Dec 05 09:52:12 beast _7_ LVM2: create_container_set_objects: Exit. Return value = 12
Dec 05 09:52:12 beast _7_ LVM2: lvm2_set_objects: Exit. Return value = 12
Should I be applying lvm2_metadata.c.patch? It seems like that patch
addresses a LVM2 metadata discovery issue. So it would seem this is this
something entirely different, correct? FYI, even if I reduce the size of
the raid region to 1.14TB I still get the same as above.
On Sun, Dec 05 2004 at 07:42,
Kevin Corry <kevcorry@...> wrote:
> Yes, you're probably hitting a size limitation in the LVM1 plugin. There are
> actually quite a few odd, mostly undocumented size limitations due to 16-bit
> and 32-bit fields in the LVM1 metadata. The one you seem to have hit is due
> to using a PV that is greater than 2TB. The size of each PV is stored in that
> PV's PV-header, and is stored in a 32-bit field. During discovery, when the
> LVM1 plugin finds a PV-header on an object, it then checks the size of that
> object against the size stored in the PV-header. If they don't match, then it
> assumes that object isn't actually a valid PV. This is the case you're in,
> and that is why you can create the container, but then it disappears when you
> restart EVMS.
> You're best bet is just to use the LVM2 plugin to create your container. It is
> a considerable improvement over the LVM1 metadata. It actually uses ASCII
> text to store most of the information about the group, and uses 64-bit fields
> in the binary header sections. You shouldn't see the above problem if you
> switch to the LVM2 plugin.
> Kevin Corry
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> Evms-devel mailing list
> To subscribe/unsubscribe, please visit: