Date: Sat, 09 Jun 2001 10:34:42 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: patl@Phoenix.Volant.ORG Cc: Peter Wemm <peter@wemm.org>, FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] Message-ID: <3B225E32.484672C@mindspring.com> References: <ML-3.4.992018636.5562.patl@asimov.phoenix.volant.org>
next in thread | previous in thread | raw e-mail | index | archive | help
patl@Phoenix.Volant.ORG wrote: > > On 8-Jun-01 at 08:30, Peter Wemm (peter@wemm.org) wrote: > > Terry, the 'cache coherency' bugs have been fixed in > > -current for ~8 months now (September 2000). The > > infrastructure changes for this are subject to a > > call-for-review right now for a merge to 4.x. > > This is -VERY- good news. I just have two questions: > > 1. Which currently broken filesystems in STABLE become usable with > these fixes? The fix is _my_ design. It permits the code to get the backing object for a vm_object_t, instead of an alias. I first proposed this design in 1995, as _part_ of a total fix (in other words, it will not fix the entire problem space). In answer to your question, the FS's which become usable are the ones for which the final VP is the local media file system, and for which there are no transformations in the FS's layered on top of it. This will work for nullfs (obviously), unionfs (assuming that the using is on a per file basis, or, minimally, at a page granularity, for interleaved FS's, and similar FS's. It will also work for adjunct metadata FS's, where the memtadata is stored seperately, such as my "quotafs", which allows "UFS quotas" to be applied to any FS on which you stack them. It will _NOT_ work for cryptographic FS's, where the number of pages or the page boundaries change witing a file, compressing FS's, FS's with different block sizes (such as a DVDROM FS, which need to deal with 1024 byte sectors for an ISO 9660 FS, along with raw CD tracks), etc.. It will _NOT_ deal with paging issues from a 1024b block size FAT opr VFAT or VFAT32 FS, when aligned at a 512b boundary (the most common case, when such an FS occurs immediately after the MBR and partition table), and it will not work for more interesting FS's which do namespace folding or support things like ISO-8859-1 to ISO-10646 namespace translation on directories (an obvious use for stacking FS layers, to provide compatability). Similarly, binary compatability between, e.g. UFS on a little endian vs. a big endian FS, implemented in a stacking layer, will not work, for systems where the atomic types are inequal (c.v. the recent time_t discussion). In other words, the code will work in about 1/4 of the cases... which, however you look at it, is a hell of a lot better than 0 of the cases, and _does_ represent forward progress. It's just not the panacea that Peter makes it out to be. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B225E32.484672C>