Path: utzoo!attcan!uunet!husc6!encore!pinocchio!peralta
From: peralta@pinocchio.Encore.COM (Rick Peralta)
Newsgroups: comp.unix.wizards
Subject: Re: bigger longs (64 bits)
Summary: bseek(fd, off_t, whence) anyone?
Message-ID: <11083@encore.Encore.COM>
Date: 7 Feb 90 22:50:33 GMT
References: <11071@encore.Encore.COM> <4812@amelia.nas.nasa.gov>
Sender: news@Encore.COM
Reply-To: peralta@pinocchio.UUCP (Rick Peralta)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 32

In article <4812@amelia.nas.nasa.gov> (David A. Truesdell) writes:
>peralta@pinocchio.Encore.COM (Rick Peralta) writes:
>
>>Does anyone have arguments (applications) for using 64 bits?
>>
>>A few that come to mind are:
>>
>>	. larger disk storage
>>	  (no joke single volumes will be breaking lseek() soon)
>
>lseek is already "broken" here.  I'm in the process of testing a striped
>filesystem which currently weighs in at 20 GigaBytes, with a production size
>expected to be 200+ GB.  

Have you standardized your new seek?  I was playing with the idea of
implementing bseek(fd, 64bits, whence);  It seemed kind of nasty to start
with but got quite reasonable quickly.

Inside the kernel space the address can be easily broken up into block size
(1K-8K) chunks, indexing into the device done and then the remainder of the
address can be used to setup the details of the position.  This seemed like
a nice perk for backward compatibility too.  Just have a union for each block
size and juggle away.  The application could play the same game and not be
constricted by the actual block size.

Of course things like ftell would break.  Maybe the address of the off_t
could be passed into bseek and the new offset returned in the variable
(gack!  I think I've been looking at too much AT&T source).  The return
value would then be status information.


 - Rick (Or maybe you are a floating point fan... 8^)