From owner-freebsd-fs Wed Aug 18 10:31: 5 1999 Delivered-To: freebsd-fs@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id CAB8914F2D; Wed, 18 Aug 1999 10:31:02 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id KAA16496; Wed, 18 Aug 1999 10:30:39 -0700 (PDT) Date: Wed, 18 Aug 1999 10:30:39 -0700 (PDT) From: Bill Studenmund To: Poul-Henning Kamp Cc: Terry Lambert , Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <830.934961572@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: > In message , 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-fs" in the body of the message