Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Aug 1999 10:30:39 -0700 (PDT)
From:      Bill Studenmund <wrstuden@nas.nasa.gov>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        Terry Lambert <tlambert@primenet.com>, Alton Matthew <Matthew.Alton@anheuser-busch.com>, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG
Subject:   Re: BSD XFS Port & BSD VFS Rewrite 
Message-ID:  <Pine.SOL.3.96.990818101005.14430B-100000@marcy.nas.nasa.gov>
In-Reply-To: <830.934961572@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:

> In message <Pine.SOL.3.96.990816105106.27345H-100000@marcy.nas.nasa.gov>, 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.96.990818101005.14430B-100000>