Hi Guest.
>>>> Q> /dev/hda5 219 379 1293200 83 Linux native
>>>> Q> /dev/hda6 380 623 1959898 83 Linux native
>>>> Note that the reason for splitting /dev/hda5 and /dev/hda6 into
>>>> two partitions was to avoid problems connected with the 2G limit
>>> Which 2 GB limit??
>> ... there have ... been claims that some of the utilities used
>> with Linux can and will mangle partitions over 2G in size on
>> 32-bit architectures.
> Such rumour-mongering is harmful for Linux.
> Either it is false, and then spreading such rumours is a very
> bad idea (one hears the same false statements about the size of
> swap partitions being repeated for more than five years, no
> amount of contradiction suffices to kill the falsehood) or there
> really are utilities with such problems, and then they should be
> fixed.
The reason I said "there have also been claims" is because it's true:
Such claims HAVE been made, so I would be lying if I said otherwise.
Thanks for warning us that you go around blindly repeating
the nonsense that people say.
The ONLY case I have come across of a utility with anything resembling
such a problem is mkisofs, which is considerably slower when creating
the image in a 2.1G partition than when creating the same image in a
1.9G partition
Excellent. So, no mangled partitions but just a rumour that in a certain
situation, on a certain machine a certain program was slower on a big
partition.
Just to convince myself that there is no problem here, I created a mkisofs image
on four ext2 partitions on the same disk, where these partitions had sizes
1.5 GB, 1.9 GB, 2.1 GB, 4.5 GB. The timings were, respectively
on 1.5GB partition: real 347.81, user 12.53, sys 41.62
on 1.9GB partition: real 345.45, user 11.91, sys 41.08
on 2.1GB partition: real 344.20, user 12.34, sys 41.18
on 4.5GB partition: real 321.48, user 11.86, sys 40.85
No significant correlation between partition size and time,
I would say. In fact the times are surprisingly uniform.
[This was Linux 2.3.3 on a 64 MB Pentium 166 MHz and a 17 GB Maxtor disk model 91728D8.]
The conclusion must be that the unqualified statement
"mkisofs is considerably slower in a 2.1G than in a 1.9G partition"
is false. If mkisofs is slower in one situation than in another
then we must ask: which partition was closest to the outer rim
of the disk? how fragmented were the filesystems? Etc.
So, for the time being, no one has shown any problem with large partitions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/