[Tfug] 64 bit file server?

[dave jordan]

>> Assuming your machine is strictly 32 bit with huge blocks:

>> 4294967295 * 4294967295 are addressable anyways.

the * is the key.  a 64bit proc can do this multiplication in fewer
clock ticks than a 32bit one.  don't quote me on this, but i would
assume that the 64-bitter does it in 1 tick and guess that the 32-
bitter does it in ??? a dozen.

-dave


On 7/8/05, Stephen Hooper <schooper at email.arizona.edu> wrote:
> On Fri, 2005-07-08 at 12:23 -0700, dave jordan wrote:
> > i think just about all modern filesystems allow them, it's a matter of
> > how efficient the creat/open/read/write code is on a 32 v. 64 bit proc
> 
> Sorry, I should have been clearer...
> 
> For 64bit to make sense wouldn't you need files that can grow to
> 18446744073709551615 (2^64 - 1) blocks, or have more than
> 18446744073709551615 bytes in a block?
> 
> Otherwise aren't you just playing with offsets anyways?
> 
> Maybe I don't understand the code well enough, but I thought that
> basically:
> 
> Assuming 1-byte block (I know it is unrealistic):
> 
> read byte 100
> open disk
> read filesystem, find beginning block in list.
> recurse list until you hit block 100/1b (100).
> read block 100.
> return byte 0.
> 
> Assuming a 4K block:
> 
> read byte 100
> open disk
> read filesystem, find beginning block in list
> recurse list until you hit block 100/4K (0)
> read  block 0
> return byte 100 from block 0
> 
> So in my way of thinking with bigger numbers all you are really doing
> (unless the filesystem supports it), is padding more zeroes in the
> front, and increasing the division that system calls like lseek have to
> do (which is probably negligible anyways).
> 
> Assuming your machine is strictly 32 bit with huge blocks:
> 
> 4294967295 * 4294967295 are addressable anyways.
> 
> Which seems like a helluva a lot.  I have never been good at math
> though, so maybe I am just not doing things right.
> 
>