Date: Sun, 10 Mar 2002 20:53:30 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Terry Lambert <tlambert2@mindspring.com>, Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t + timestamps? Message-ID: <p0510153cb8b1b82f04da@[128.113.24.47]> In-Reply-To: <3C8C03DB.E673B495@mindspring.com> References: <65691.1015791493@critter.freebsd.dk> <3C8C03DB.E673B495@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 5:09 PM -0800 3/10/02, Terry Lambert wrote:
>Poul-Henning Kamp wrote:
>> >As to strategy, I guess we could start by adding two new fields to
>> >'struct stat', which would be the 64-bit ones. We could truncate
>> >the 32-bit value and put that in the current fields. Some #define
>> >would govern whether a program sees st_dev and st_ino as the 32-bit
>> >values or the 64-bit values. That's the easy solution to the struct,
>> >but of course it doesn't address all the things which work with
>> >dev_t and ino_t. That's what we would have to work on over time.
>>
>> No, we can't change the size of struct stat (binary compatibility!)
>
>I think the first thing we would change, wee we to "go hog
>wild" would be to make times in seconds 64 bits, anyway...
I meant to mention that too, as I believe UFS2 is also going to
switch to 64-bit timestamps. I forget where we left the discussion
of 64-bit time_t types though. I have a few messages saved away in
a thread by Peter Wemm which suggest we could:
1: time_t assumptions in existing code should be fixed.
2: new platforms should start at time_t 64 bit
3: Once we've tested the water on the new platforms, *then*
progress towards activating it on alpha and then x86.
By then we'll have gathered enough *experience* on the new
platforms to know how much pain the alpha and i386 will have,
and we can judge whether its worth it. Until then, we're
speculating. We have no hard data and no actual real experience.
I don't know if we're really doing step #2 on the new platforms yet,
although my interest-level increases now that sparc64 is getting to
be a real port! :-)
but at the very least, I do think we could add fields for 64-bit
timestamps in 'struct stat' at the same time as we add 64-bit
fields for dev_t and ino_t. The stat() routine doesn't have to
fill them in, but we would just define them to increase the size
of the struct so that room will be there down the road.
Either that, or just give up on stat()/lstat() as being too hard to
modify, leave them in stone forever, and provide some new stat-like
routines which both fix the immediate issues and are more flexible
when it comes to any future issues. Even if the new routines are
just-like-stat except that they include a length-field so the
called routine knows how big the stat-area is.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0510153cb8b1b82f04da>