Skip to contentSkip to conversation

LVM and striping, defragmentation

linux-lvm Urs Thuermann 3 participants 3 messages Feb 26, 2001 – Feb 28, 2001

lore
Share & tools
lore
#0 lore raw

I'd like to experiment with LVM and striping. The HOWTO at www.linuxdoc.org says in section 8.3 LVM native striping

Performance notices

The performance 'gain' may well be very negative if you stripe over 2 partitions of the same disk - take care to prevent that.

How can I take care of it? I've seen no option in lvcreate to specify where the PE should be taken from. If I have a VG with only two PVs on two different disks, will LVM automatically choose PEs from the two PVs instead of one PV? And what if I have a VG with several PVs on disk A and several PVs on disk B. How can I "take care to prevent" that LVM does not choose two PEs from the same disk for striping?

When I resize my LVs in a VG multiple times, I can get some fragmentation, i.e. LVs in the VG are not contiguous. Is there a tool to defragment LVs, i.e. to swap PEs so that all LVs in the VG are contiguous again. I read in the man page that the allocation policy can be set to "contiguous", but how can I make LVs contiguous after some creating, removing, and resizing of LVs?

How much performance loss is to be expected in case of non-contiguous LVs?

urs

#1 lore raw
Quoted 9 lines · Urs Thuermann

I'd like to experiment with LVM and striping. The HOWTO at www.linuxdoc.org says in section 8.3 LVM native striping

Performance notices

The performance 'gain' may well be very negative if you stripe over 2 partitions of the same disk - take care to prevent that.

Quoted 6 lines

How can I take care of it? I've seen no option in lvcreate to specify where the PE should be taken from. If I have a VG with only two PVs on two different disks, will LVM automatically choose PEs from the two PVs instead of one PV? And what if I have a VG with several PVs on disk A and several PVs on disk B. How can I "take care to prevent" that LVM does not choose two PEs from the same disk for striping?

You have highlighted an area where we want to do more work. Specifically we want to write a tool that allows you more control over the LE->PE mapping. The striping allocation will try and allocate LE's from two different PV's in the VG. When you create the striped LV just try not to have two PV's on the same disk. You can always disable allocation on an individual PV basis.

Quoted 6 lines

When I resize my LVs in a VG multiple times, I can get some fragmentation, i.e. LVs in the VG are not contiguous. Is there a tool to defragment LVs, i.e. to swap PEs so that all LVs in the VG are contiguous again. I read in the man page that the allocation policy can be set to "contiguous", but how can I make LVs contiguous after some creating, removing, and resizing of LVs?

At the moment it's not easy, you might want to look at the pvmove documentation.

Quoted 1 line

How much performance loss is to be expected in case of non-contiguous LVs?

It shouldn't be large, the LE's are normally 4 meg so the seeks to different parts of the disk won't be that frequent. To contrast with stripes where the chunk size defaults to 64K, which can cause a lot of thrashing if the stripes are on the same disk.

- Joe

#2 lore raw
Quoted 10 lines · Joe Thornber
Quoted 9 lines · Urs Thuermann

I'd like to experiment with LVM and striping. The HOWTO at www.linuxdoc.org says in section 8.3 LVM native striping

Performance notices

The performance 'gain' may well be very negative if you stripe over 2 partitions of the same disk - take care to prevent that.

Quoted 6 lines
Quoted 6 lines

How can I take care of it? I've seen no option in lvcreate to specify where the PE should be taken from. If I have a VG with only two PVs on two different disks, will LVM automatically choose PEs from the two PVs instead of one PV? And what if I have a VG with several PVs on disk A and several PVs on disk B. How can I "take care to prevent" that LVM does not choose two PEs from the same disk for striping?

Having more than one PV mapped to a physical device is *not* the recommended production configuration. The only reason why we build in that option is flexibility in test configurations.

Quoted 7 lines

You have highlighted an area where we want to do more work. Specifically we want to write a tool that allows you more control over the LE->PE mapping. The striping allocation will try and allocate LE's from two different PV's in the VG. When you create the striped LV just try not to have two PV's on the same disk. You can always disable allocation on an individual PV basis.

Check the lvcreate man page, please.
You can add a list of PV device specials to allocate the PEs from to the lvcreate command line or use pvchange in order to prohibit allocation on that PV before using lvcreate.

Quoted 23 lines
Quoted 7 lines

When I resize my LVs in a VG multiple times, I can get some fragmentation, i.e. LVs in the VG are not contiguous. Is there a tool to defragment LVs, i.e. to swap PEs so that all LVs in the VG are contiguous again. I read in the man page that the allocation policy can be set to "contiguous", but how can I make LVs contiguous after some creating, removing, and resizing of LVs?

At the moment it's not easy, you might want to look at the pvmove documentation.

Quoted 1 line

How much performance loss is to be expected in case of non-contiguous LVs?

It shouldn't be large, the LE's are normally 4 meg so the seeks to different parts of the disk won't be that frequent. To contrast with stripes where the chunk size defaults to 64K, which can cause a lot of thrashing if the stripes are on the same disk.

- Joe
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm

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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-