Debarshi 'Rishi' Ray wrote:
> Is it the /proc/partitions which can get huge? Or can /proc/devices be
> huge too? By the way is there an upper limit for the device major
> numbers? I am just curious.
Both can get large and 16KB sort of plays it safe.
But /proc/devices lists the major device numbers for the devices on
the system. So is not 16KB too big a size for such a file? I thought
on systems with less than 64 MB of memory, 16KB can be too much of a
demand at times.
I can't think of a system where this would be a problem. 16KB is not
much of a strain.
You want to avoid multiple read passes across /proc in general, which
is why
16KB was chosen.
If you think it is alright and necessary to have 16KB, then let's have
it. :-)
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.
Being able to access volume groups via parted doesn't seem necessary
anyway.
Why so? 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.
--
David Cantrell
Red Hat / Westford, MA
_______________________________________________
parted-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
