Thus far, I've been making an argument that WAFL is an underlying infrastructure for building file systems by observing that it serves the basis for two distinct distributed file system technologies, and has served as the basis for a streaming media file system.
But the problem with that argument is that it asks the reader to buy into the notion that there is a smallest unit of software that is a file system and anything less than that is not.
The fact that WAFL supports SAN storage and the way in which it supports SAN storage is, in my mind, a more compelling argument.
But a brief digression on What is a LUN?
The key intuition is that a LUN, fundamentally, is a logical organization of disk blocks. It turns out that a logical organization of disk blocks requires some on-disk data structure. And it turns out that the on disk data structures that represent a file can be used to represent a LUN.
However, just because the on-disk data structure that tracks disk blocks happens to be the same as a file, does not mean that the LUN is accessed or manipulated in the same way a file is.
LUNs and WAFL
This picture, I hope, explains the layering of SAN on WAFL. SAN uses some WAFL primitives, in particular the ability to read and write disk blocks but does not use all of the primitives.
Furthermore, not illustrated in this diagram is that there are specific optimizations within the read and write paths to get the kind of performance that SAN customers expect.
Now because the underlying data structures required to read from disk are the same as the ones NFS uses to manipulate files, an interesting side effect emerges, namely an NFS client can access see the LUN as a file. But remember, when NFS is accessing the LUN it’s going through a different path through the system. More to the point, the on-disk object is only a file when you go through the NFS stack, not when you go through the LUN path.
If you have any kind of object oriented programming language training, you could almost say the following:
That an inode is the on-disk object, and a LUN IS-A inode, and a FILE IS-A inode, but a LUN is not a FILE.
Okay, so, what’s the point?
The point is that WAFL is the part of the code that provides the “read or write from-disk” mechanisms to both NFS and CIFS and SAN. The semantics of a how the blocks are accessed are provided by higher level code not by WAFL, which means WAFL is not a file system.
