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>