At 00:42 25/07/02, Alexander Viro wrote:
>On Thu, 25 Jul 2002 Andries.Brouwer@cwi.nl wrote:
> > Just saw some new partition code in 2.5.28. Good!
> > I like almost all I see, except for one thing:
> >
> > +struct parsed_partitions {
> > + char name[40];
> > + struct {
> > + unsigned long from;
> > + unsigned long size;
> > + int flags;
> > + } parts[MAX_PART];
> > + int next;
> > + int limit;
> > +};
> >
> > and I object to the long instead of u64 or so.
>
>Separate set of patches. As it is, struct hd_struct is still there and
>still not modified. And it has unsigned long. It will become sector_t.
>
>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.
>
>That stuff becomes an issue for 2Tb disks. Do we actually have something
>that large attached to 32bit boxen?
Not right now perhaps, but we may well do in a year or two. E.g. in the
department, we just bought a Dual Athlon 2000+, 3G RAM, and attached it to
a new 1.4TiB RAID array. We only need HDs to double in size and that array
could easily become 2.8TiB... And the whole fun costs less than US$15,000
at present so it is quite affordable for smaller institutions/companies.
OTOH, we are going to be using 32-bit systems for quite a few years to come...
> > With 2^32 sectors one can handle up to 2^41 bytes, 2 TiB.
> > Already today people want RAIDs that are larger, and
> > few years from now we'll have single disks that are larger.
>
>... and still use i386 with these disks?
Yes, definitely. Why pay for some stupidly expensive 64-bit computer when
you only want large storage?
>ia64 is stillborn, but x86-64 promises to be more useful than Itanic.
We shall see once it comes on the market... And we will then see the price
tag it will bring with it, too...
>u64 for sector_t doesn't change anything for 64bit boxen that might be
>interested in really large disks and screws 32bit ones that shouldn't
>have to pay for that...
True. That's why sector_t should be a compile time option in the kernel
"Enable large device support > 2TiB: Y/N". Then I am happy and loads of
other people because we can use large raid arrays without having to buy the
latest expensive system and other people are happy for having faster 32-bit
code... Surely we can write robust enough code which will work with either
sector_t size...
Best regards,
Anton
-- "I've not lost my mind. It's backed up on tape somewhere." - Unknown -- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/- 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:18 EST