🚀 go-pugleaf

In article <44gsu7$re4@sernews.raleigh.ibm.com>,  <mayhew@vnet.ibm.com> wrote:
[snip...]
>I have also measured maximum file sizes, ignoring the files generated by
>databases that like to keep everything in just one file. While average file
>size is relatively small, maximum file size has, in my experience, broken
>into the 100 megabyte range. Discussions with some friends in the text
>retrieval business has indicated that individual GB size files are sometimes 
>useful, but that larger logical data stores are more, or just as, easily 
>handled by some arbitrary partitioning into sub GB files. I do not doubt that
>there are some limited number of applications and users that have needs
>that transcend the 32-bit addressing boundary, I just do not think this is the
>general case. 

I respectfully disagree.  In my field -- environmental modeling -- the
need to live within dinky little 2GB file size limits has has a profound
impact on the way we do things (a study that _ought to be_ just a dozen
or so program executions becomes several *thousand* program executions,
and a serious management problem, for example).  And if multimedia 
computing becomes "fashionable", lots of users are going to want to
deal with large files.  Conversely, to the extent that we are stuck
with 32-bit file systems, applications such as multimedia will be
stalled.

<flame on>
and to the extent that C compiler writers fail to provide *standard
integer types* suitable for subscripting objects in large mmap()ed 
files, they should be shot.  And their employers ostracized.
<flame off>

fwiw.

Carlie J. Coats, Jr.              coats@ncsc.org    *or*    xcc@hpcc.epa.gov
Environmental Programs                                  phone: (919)248-9241
North Carolina Supercomputing Center                      fax: (919)248-9245
3021 Cornwallis Road                                         P. O. Box 12889
Research Triangle Park, N. C.  27709-2889                                USA
"My opinions are my own, and I've got *lots* of them!"