On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bill
> Studenmund writes:
> >On Sat, 14 Aug 1999, Terry Lambert wrote:
>
> Matt doesn't represent the FreeBSD project, and even if he rewrites
> the VFS subsystem so he can understand it, his rewrite would face
> considerable resistance on its way into FreeBSD. I don't think
> there is reason to rewrite it, but there certainly are areas
> that need fixing.
Whew! That's reasuring. I agree there are things which need fixing. It'd
be nice if both NetBSD and FreeBSD could fix things in the same way.
> >> The use of the "vfs_default" to make unimplemented VOP's
> >> fall through to code which implements function, while well
> >> intentioned, is misguided.
>
> I beg to differ. The only difference is that we pass through
> multiple layers before we hit the bottom of the stack. There is
> no loss of functionality but significant gain of clarity and
> modularity.
If I understood the issue, it is that the leaf fs's (the bottom ones)
would use a default routine for non-error functionality. I think Terry's
point (which I agree with) was that a leaf fs's default routine should
only return errors.
> >> 3. The filesystem itself is broken for Y2038
> >One other suggestion I've heard is to split the 64 bits we have for time
> >into 44 bits for seconds, and 20 bits for microseconds. That's more than
> >enough modification resolution, and also pushes things to past year
> >500,000 AD. Versioning the indoe would cover this easily.
>
> This would be misguided, and given the current speed of evolution
> lead to other problems far before 2038.
>
> Both struct timespec and struct timeval are major mistakes, they
> make arithmetic on timestamps an expensive operation. Timestamps
> should be stored as integers using an fix-point notations, for
> instance 64bits with 32bit fractional seconds (the NTP timestamp),
> or in the future 128/48.
I like that idea.
One thing I should probably mention is that I'm not suggesting we ever do
arighmetic on the 44/20 number, just we store it that way. struct inode
would contain time fields in whatever format the host prefers, with the
44/20 stuff only being in struct dinode. Converting from 44/20 would only
happen on initial read. Math would happen on the host format version. :-)
If time structures go to 64/32 fixed-point math, then my suggestion can be
re-phrased as storing 44.20 worth of that number in the on-disk inode.
> Extending from 64 to 128bits would be a cheap shift and increased
> precision and range could go hand in hand.
I doubt we need more than 64 bit times. 2^63 seconds works out to
292,279,025,208 years, or 292 (american) billion years. Current theories
put the age of the universe at I think 12 to 16 billion years. So 64-bit
signed times in seconds will cover from before the big bang to way past
any time we'll be caring about. :-)
Take care,
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
