Re: Online creation/extension of Tablespaces possible??

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<4144c5d1$0$968$afc38c87_at_news.optusnet.com.au>...
>
> Last time I checked, 2^32 was 4GB, not two. So that's not the consideration
> here, surely? We're talking practical backup/recovery/performance issues,
> not theoretical limits.

Careful. Many *nix file systems used a file locator that is a signed integer of 32-bit. Since you need one bit for the sign, you get a max addressability of 2Gb out of your 32 bit counter. Hence the "traditional" 32-bit *nix limitation of 2Gb for a file.

Why is it a signed integer? Beats me, although I have a recollection somewhere of negative addresses being valid in some file system types. There is a site with the history of Unix and how these things came to be, straight from the horse's mouth (Ken Thompson) if you are interested.

Most recent file systems will use a 64-bit file location counter. For that they use a data type that is called in "C" a "long long"... This works even if the OS is still mostly 32-bit. Most modern C compilers will handle that data type either through emulation of a 64-bit ALU or directly if the CPU supports it. This is also the case for many Lunix file systems, IIRC. And certainly the case for most of the latest releases of *nix.

Windows NTFS hasn't had a 2Gb limitation for yonks. AFAIK, it never had. It is however limited in using only the first 2Gb of memory for direct I/O buffering. This is why AWE uses that quaint "expanded memory window" technology, plucked straight from the days when "640K was more than anyone would ever need"...

I'd agree with your 2Gb "rule of thumb" up until about two years ago. Nowadays, I find little qualm in using 16Gb instead. Most systems where that sort of file size might be needed can easily cope with a LOT more anyway. And having too many files open can still (unreal, eh?) harm most OSs out there.

Of course: YMMV, IMHO, NAWHTT, etcetc. Received on Mon Sep 13 2004 - 00:17:42 CDT