RE: New LVM?

["Staniec, Joel" <Joel Staniec handleman com>]

There is a wish list for new LVM and that's what I am looking for.



LVM 1.0.3
						$Date: 2002/02/19
16:23:54 $
TODO list for future LVM versions                       


Numbers don't imply priority! A lot of this is already in the LVM2 code
base.

1. Implement downcall function to activate snapshots to support atomic
   activation triggered by the snapshot user (like file and database
systems)

2. Enhance lvdisplay to calculate the maximum possible extension
   for a logical volume (free PEs in VG, allocation policy)

3. Support VGDA changes by vgchange(8) to use free space between VGDA
space
   on disk and first PE to extend/reduce number of PVs

4. Support merge of volume groups with different physical extent sizes

5. Support special file name space for raw devices (SCT)

6. Write mini-howto for filesystem integrators

7. Implement a daemon which automagically moves i/o intense physical
   extents to physical volumes with low i/o based on available statistic
data

8. Enhance LVM to be cluster aware

9. Implement special handling of unavailable physical volumes (aka
quorum)

10. Implement multipathing

11. Enhance LVM driver to be able to read the VGDA at boot time

12. Remove dependencies not covered by LVM_DIR_PREFIX from code to
    enable different /dev/ namespaces

13. Implement metadata redundancy in order to enable fast recovery

14. Read ahead support doesn't work on a per LV base:
    additional kernel changes necessary

15. Display information in case vgscan finds a correct PV structure in
    a partition with a wrong partition type identifier in order to
    point the administrator to change that

16. Implement PV <-> UUID mapping support in the driver

17. Add config file support

18. Remove suser checks

19. Afford political discussion with Linus in order to have
/proc/partitions
    support for LVs in the stock kernel

20. Implement general and more likely reusable metadata format in
    vg_cfgbackup()/vg_cfgrestore()

21. Add command line support for UUIDs to pvdisplay, pvchange?,
vgdisplay,
    vgremove, vgextend, vgreduce, vgimport and vgexport

22. Enhance vgimport to work with just a given VG name or VG UUID rather
    than an additional list of PV pathes

23. Support extension of stripes beyond a single physical device


Joel T. Staniec
Handleman Company 
Manager of Operations Technology - Technology Management Group 
Voice Mail  : 248 - 362 - 4400 - X130
E-Mail : joel staniec handleman com


-----Original Message-----
From: taroon-list-admin redhat com [mailto:taroon-list-admin redhat com]
On Behalf Of Arjan van de Ven
Sent: Friday, October 31, 2003 3:34 PM
To: taroon-list redhat com
Subject: Re: New LVM?

On Fri, 2003-10-31 at 15:23, Staniec, Joel wrote:
> Any idea when the new LVM is coming out?
> 
>  
what do you mean ?