Date: Mon, 13 May 2002 10:16:42 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: arch@FreeBSD.org Subject: Future of IFS Message-ID: <Pine.NEB.3.96L.1020513100246.69160t-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
As many of you know, we have a number of "variants" on the UFS/FFS theme in src/sys/ufs. In the past this has included mfs (now axed) and lfs (now axed). Currently, the denizens are ufs, ffs, ifs, and ext2fs. With the impending commit of a first draft of UFS2, we probably need to decide what's happening with each of these. The topic of this e-mail is IFS. IFS provides a "short circuit" to access the filestore mechanism defined in FFS. It optimizes out the namespace for application services requiring a filestore, but providing their own namespace/meta-data, and not wanting to pay the cost of the filesystem namespace/meta-data service (either in time for synchronous operation, or memory for soft updates). Typically, this type of filestore service is used for applications like Squid caches, or could be used for applications like Coda that provide the namespace as a pseudo-stack above the cache filestore. In the past, services such as AFS have attempted to avoid paying the price of the namespace through calls such as iopen() or fhopen() (*). IFS permits these applications to run cleanly above the filestore. However. IFS currently does not have an active maintainer (Adrian Chadd has indicated that his priorities currently lie elsewhere), and as far as I know, we have no applications in the ports tree that make use of IFS. This doesn't mean there aren't consumers of IFS, or no potential maintainer, just that I don't know of them. The UFS2 commit is going to involve a fairly extensive overhaul of the FFS code, as well as having its hands in the UFS tree. Without an active maintainer and active consumers, the IFS code is probably not something that can be maintained in the tree over this sort of change. I know Adrian had expressed the intent of axing and re-implementing the current code in time for 5.0. So... The question: Are you (or have you ever been **) an active maintainer or consumer of the IFS code. Will you notice if IFS evaporates from the souce tree? Unless we have a highly active maintainer who can fix the IFS problems that will turn up with the UFS2 commit, it would probably be best to simply remove it now. Pending a healthy and lively volunteer on the IFS front, I will do so immediately following the commit of UFS2. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services * An interesting question that has not been answered experimentally (in a published form) is whether or not this continues to be an important performance optimization. In the past, it has been, but the behavior of systems has changed substantially since the last such performance analysis I've seen. ** A member of the communist party. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020513100246.69160t-100000>