[parted-devel] Re: Patch against SVN (1.8.0rc2): number two

[David Cantrell]

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