[Tfug] 64 bit file server?

[Stephen Hooper]

On Fri, 2005-07-08 at 13:29 -0700, dave jordan wrote:
> >> 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.

Ok,

But following my pseudo-pseudo-code (assuming that is indeed correct
which of course it probably is not), that multiplication would never be
necessary:  you would need a / (/mod actually), but even then only to
break out the relative position of (2 ^ 32 - 1) * (2 ^ 32 - 1) into
block number and offest, and recursion through a list (increment).

So, lets you have a block map for a file:  1-3-5-7-9 ... 13

What I need to know to read any point in that file is which block, and
the offset into that block.

I am given a number by a programmer (like me :}), that is something like
1067.  Which is reasonable from the programmer's perspective because he
he just wants to read (seek, or whatever) to byte 1067 of the file.

So (assuming a 1K block):

1067 /mod 1024 ( (no such C animal as /mod that I know) 1 43 )
block_counter = 1
offset = 43
block =  block_map[block_counter] from disk (get the contents of block
3)
block + offset == byte I am interested in.

Of course, I am sure things are much more complicated in real life, but
I think the preceding is sort of valid.

That means that with a thirty two bits you can accomodate files of size
(2^32-1) * (2^32-1) (although I doubt anyone much does, because you
would need a 4G? block).  

The advantage of 64 bits would be that you could increase the file size
to (2^64-1) * (2^64 -1) (which is probably too large for me to even
guess at).

Otherwise, I think you are pretty much buying yourself... nothing. Maybe
you can divide a little faster on 64-bit hardware, but I doubt it...
there are probably tricks to make the division step less costly (bit
shifting/masking), and hence nullify the whole division thing anyways.

As you point out, on even the fastest processors the multiplication is a
slowdown.  It is much cheaper to bit-shift, or mask.

This of course is a pretend world, where we are dealing with just whole
words.   I can see some use in increasing to 64bit for a filesystem, if
we deal with parts of words.  Let's say the top 12 bits of a thirty two
bit number are the block, and the bottom 20 are the offset then it makes
a little more sense as you can increase those numbers by a little, and
still just be moving around words in memory.  

This would only really be useful when addressing the disk directly
anyways (I think), but still, the x86 line does support weird word sizes
in some cases (48bits jumps out of my memory), but you still end up in a
block offset quandry:  I doubt you would ever want to try, pull more
than a handful of K off a disk at once, and how many blocks should a
file occupy?