On Mon, 26 Jun 2006, Richard L. Hamilton wrote:
One thing: if it's not already in there, please consider including history of changes since at least Solaris 7. There's something in particular (FiST - see http://www.filesystems.org/) that was written to work on both Linux, FreeBSD, and Solaris 7, and there might be more of a chance of getting it updated if it was clearer what changes needed to be made.
Hmm, I do understand the request, but it's beyond the scope of what I've started to do. It'd make sense, but writing up a "changelog" even between S9 and S10 in the filesystems area is a _huge_ task, and doing so all the way back to S7 would end up in a (multi-volume) book. All interesting to know, I admit, and even interesting to create - but life's short ...
We do hope that OpenSolaris, resp. the putback logs / SCCS history that now is available, will over time allow the construction of such a changelog at least for modifications that go in now. But even documenting the "now" is titanic work :(
Just look at the main new ufs features since 2.7 - logging performance, directio concurrency, dnlc enhancements, space preallocation, new vfs and vnode interfaces; and that's only one filesystem, doesn't touch on VM things interrelated that were done as well, doesn't mention pseudo filesystems, and of course makes no comment on "paths explored but not published" (yes, there _were_ projects in filesystem land that are now in bit heaven ...).
I'd love to have a "Solaris filesystem evolution" chart/map, but I know if I set out to draw it I'll loose myself in the details. Like finding some similarities between the ZFS ZIL code and UFS logging's crb buffering. Or showing how all Solaris FS drivers derived the strange readdir/dirlook code duplication from some early ufs versions. Or the unreadable for() loop in *_getapage() that everyone uses. Or or or.... there are patterns all over, and history's footprint everywhere. A colleague of mine once quoted McKusick in a remark the latter was said to have made about the Solaris UFS code back in the 2.4 days - "I feel young again" ...
Regarding FiST: Stacking filesystems, yet another wonderful topic that one can write books about. The Solaris filesystem interfaces don't lend themselves well towards doing stacking/filtering. There's no "reentrance" requirement / test criteria, and a filesystem driver in itself isn't strictly faulty if it fails on reentrance. But stacking _forces_ reentrance, and some of the NFS/disk-based-fs interaction problems that there are (I/O between local NFS mounts and the disk-based backend fs can lead to 'interesting' misbehaviour) are a consequence of that. That's why the only stacked fs drivers we have are lofs and nfs - there are even more 'watch out !' signs there than for disk-based filesystem drivers.
Throwing in another idea as to how to best fill this documentation hole - what do you folks think about a wiki ? Suggest contents, fill contents ?
Best wishes, FrankH.
This message posted from opensolaris.org _______________________________________________ ufs-discuss mailing list [email protected]
============================================================================ No good can come from selling your freedom, not for all gold of the world, for the value of this heavenly gift exceeds that of any fortune on earth. ============================================================================ _______________________________________________ ufs-discuss mailing list [email protected]
