Date: Wed, 18 Aug 1999 09:32:52 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Bill Studenmund <wrstuden@nas.nasa.gov> 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: <830.934961572@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 16 Aug 1999 13:48:16 PDT." <Pine.SOL.3.96.990816105106.27345H-100000@marcy.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.SOL.3.96.990816105106.27345H-100000@marcy.nas.nasa.gov>, Bill Studenmund writes: >On Sat, 14 Aug 1999, Terry Lambert wrote: >> > I am currently conducting a thorough study of the VFS subsystem >> > in preparation for an all-out effort to port SGI's XFS filesystem to >> > FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon >> > has written in hackers- that the VFS subsystem is presently not >> > well understood by any of the active kernel code contributers and >> > that it will be rewritten later this year. This is obviously of great >> > concern to me in this port. >> >> It is of great concern to me that a rewrite, apparently because of >> non-understanding, is taking place at all. > >That concerns me too. Many aspects of the 4.4 vnode interface were there >for specific reasons. Even if they were hack solutions, to re-write them >because of a lack of understanding is dangerous as the new code will >likely run into the same problems as before. :-) 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. >> 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. Adding a new VOP entails the same thing as it has always done. >> 3. The filesystem itself is broken for Y2038 >> >> The space which was historically reserved for the Y2038 fix >> (a 64 bit time_t) was absconeded with for subsecond resoloution. >> >> This change should be reverted, and fsck modified to re-zero >> the values, given a specific argument. That would break make(1) on contemporary machines. >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. Extending from 64 to 128bits would be a cheap shift and increased precision and range could go hand in hand. If we don't want to extend the size of the timestamps before 2038, (and we should not only look at filesystems here), then the correct fix will be to move the epoch and use the inode version to mark this fact. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! 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?830.934961572>