Given the number of huge datacenter situations that have been reported to me that have large /proc "info" files, I feel better leaving it at 16KB where it's been working fine for years in RHEL and Fedora Core than to reduce it to 1KB.
Ok. Point taken. After all it is not a good idea to fix something which is not broken. :-)
One may look at volume groups as the equivalent of a block device (eg., /dev/hdb) on a non-LVM set-up. Being able to 'print' out the whole list of logical volumes on a volume group and operate on it, in the same way we print out a disk's (eg., /dev/hdb) disklabel and operate on it, might be very useful. What do you think?
But it's not the same as a block device. I like what you are proposing here, but the way LVM currently works doesn't lead to this thought process. The correct way to implement something like this is to improve the LVM tools by adding a userspace library that we, in parted, can call rather than adding our own LVM code. I would rather do that than add a hack to do it this way in parted, but the LVM tools are still the way they have always been.
Maybe we can develop a complete userspace LVM library (something more mature than a hack) as part of libparted, which parted and possibly the LVM tools can use too. That way libparted will become a more complete API. Since the LVM tools are not changing by themselves, maybe this way we can intiate some change. Or would you like the library (say liblvm) to be a part of the LVM suite? Would Leslie like to comment? Happ hacking, Debarshi -- "India is not, as people keep calling it, an underdeveloped country, but rather a developed nation in an advanced state of decay." --Shashi Tharoor _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
