>> and I object to the long instead of u64 or so.
> Separate set of patches.
Good.
Although it is better to design the right data structures first.
> As it is, struct hd_struct is still there and still not modified.
> And it has unsigned long. It will become sector_t.
You need two things:
(i) A faithful representation of what the partition parser says.
Partition table parsers, in the kernel or in user space, find out
how this disk is partitioned and the information found is stored
in some "parsed partition table" struct. Here offset and length
must be u64 and use byte as a unit.
(ii) A representation of offset and length suitable to use for
block I/O. During block I/O a sector number is tested against
the max to test for errors, and the partition offset is added.
These two must of course use the units the sector number is in.
So a sector_t is reasonable here.
> Actually, I'm not all that sure that we want u64 here. The thing being,
> start_sect shouldn't be bigger than sector_t (see how it's used). And
> 64bit arithmetics on 32bit boxen sucks big way. I'm not too concerned
> about adding start_sect per se - it's done once per request and it's
> noise compared to the rest of work. However, long long for sector_t
> will hit in a lot of more interesting code paths.
It will be unavoidable soon. For many applications it is needed today.
> Al, still thinking that anybody who does mkfs.<whatever> on a multi-Tb
> device should seek professional help of the kind they don't give on l-k...
I don't see how this can be relevant. If the device is large and you
make it one big partition then the size of the partition will need more
than 32 bits. If you split it up into lots of tiny 2 TB partitions
then the offsets will need more than 32 bits.
I did my partition stuff seven years ago, and at that time discussion
was possible: is it really necessary to use 64 bits?
Today no discussion is possible. Yes, u64 is needed.
Andries
[As a separate discussion:
I used a sparse setup, that is why the struct describing a partition also
had the partition number. Your version with 256 structs looks a bit clumsy.
In most setups 256 is a waste. In some it is not enough.
Sparseness is useful for user space. But of course I had a 64-bit dev_t.]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:21 EST