[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    Re: [OT] Re: 64-bit block sizes on 32-bit systems
From:       Ion Badulescu <ionut () moisil ! cs ! columbia ! edu>
Date:       2001-03-29 23:17:19
[Download RAW message or body]

On Thu, 29 Mar 2001 21:09:53 +0100, Per Jessen <per@computer.org> wrote:

> This is academic - if people running IA32 systems are willing - and
> I think they are - to accept a performance penalty in return for the 
> ability to utilize much bigger disks/disk-space, why not let them
> have it ?

Because I'm also running IA32 systems and I'm not willing to accept
the performance penalty. And like me are numerous other who've never
thought of pushing an architecture beyond its limits.

Maybe also because academic (nee technical) arguments happen to matter
a lot more in the Linux world than commercial arguments.

You just can't expect to put a Honda Civic engine on a tank and
have it perform well. That's quite well understood. You want to
do it anyway, you're welcome to try. But please, leave us the default
Honda Civic body which this engine can manage rather well.

> Your attitude is *almost* that of Microsoft - WE know what is best for
> YOU. 

Ohh, but WE've always known what's best for YOU, otherwise we wouldn't
bother and would let YOU write YOUR OWN kernel from scratch. :-)

However, *unlike* Microsoft, we do give you full source code and allow
you to make whatever changes fancy you. You're welcome to make this
change, maintain the patch outside the official kernel and give it to
the poor sods whose management gave them the tank with the Honda Civic
engine inside. I'm sure they'll appreciate it (no sarcasm intended).

> Just to put things in perspective.

Indeed, since you mention perspective: before we continue this thread,
please all take a long and hard look at the "64-bit dev_t" thread on
linux-kernel. Judge for yourselves what the chances of Linus accepting
a 64-bit device size_t would be, in the light of that thread...

[I won't even get into the "but make it a compile option" argument.
Matthew Wilcox mentioned it breaks the module ABI compatibility; I'll
just say that we currently have 6 different (incompatible) strains --
3 memory models x {UP, SMP} -- and adding yet another option affecting
the core ABI would multiply that to 12. Thanks, but no thanks.]

EOT for me,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org

[prev in list] [next in list] [prev in thread] [next in thread]