[I'll CC freebsd-fs on my answer. -ezk]

In message <20040523032807.GC17124@afields.ca>, Allan Fields writes:
> Hi,
> Recently, the point has been raised while discussing fistgen generated
> file systems on FreeBSD: Can you update as to the current status
> of the FreeBSD-5 templates and cache coherency issues in stacking
> implementation?
> If there are outstanding issues in FreeBSD, what steps should be
> taken to address them?

Allan, last time we officially checked fist was under 5.1 and 4.9. At that
time we essentially rewrote the 4.x templates and wrote new ones for 5.x.
Both worked well, and passed a compile benchmark, fsx, and few assorted
micro-benchmarks. We haven't tried 5.2/4.10 yet, but usually you guys are
very good about keeping kernel code backward compatible, so I'm not
expecting much trouble.

Now, I'm not sure what you mean by cache coherency problems. There are two
possible issues:

1. A while back the fbsd VFS had problems, which were gradually fixed in 4.x
and 5.x. We were able to use those updates and ensured that any and all
access through our stacked f/s works well: no data corruptions etc.

2. Any stackable f/s, AFAIK, still has a problem wrt cache coherency unless
you use overlay mounts. This is true only for file systems that want to
modify file data (e.g., cryptfs). Example: I can mount cryptfs over one
directory, and access files through the mnt pt, but I could also go to
the lower file system's files directly and muck with them. So
essentially I'd be modifying two separate pages that really logically
belong to one . There is no way to inform an upper f/s of a
page that changed in the lower f/s. To resolve this completely, you need
a unified cache manager (ala Heidemann's SOSP'95 paper).

Now, if there's something new we could use in 5.x that can make it possible
for us to write cleaner and safer stacked f/s on fbsd,, we'd love to hear
about it.

freebsd-fs@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"