lkml.org 
[lkml]   [2002]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.5.28 and partitions
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/

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.072 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site