March 19, 2012 Earlier we talked about disk capacity increasing but disk access times not. NetApp’s patented file system is called WAFL which stands for Write Anywhere Layout. WAFL always writes to the nearest available free block as opposed to a preallocated location on disk…If you look at conventional file systems, such as the Veritas Fast File System, NTFS, or the Berkeley Fast File System which is used in Solaris and HP/UX, they all write to pre-allocated locations on disk meaning that lot’s of disk seeking must occur. With WAFL we write out a stripe and hopefully not even move the heads to write the next stripe (if free space in the same cylinder). If not, it’s hopefully just one head click away. Quite simply, we minimize head seeking as much as possible.
RAID-3 typically uses a very small stripe width, sometimes as small as one byte per disk. The result: RAID-3 accesses all the disk in the group at one time, and can only execute one I/O request at a time. With RAID4, access to each disk becomes independent. The stripe size is sufficiently large that the majority of I/Os to the group will only affect a single disk. This allows the RAID-4 group to execute multiple I/O requests simultaneously (assuming they map to different member disks).
RAID-3 typically uses a very small stripe width, sometimes as small as one byte per disk. The result: RAID-3 accesses all the disk in the group at one time, and can only execute one I/O request at a time. With RAID4, access to each disk becomes independent. The stripe size is sufficiently large that the majority of I/Os to the group will only affect a single disk. This allows the RAID-4 group to execute multiple I/O requests simultaneously (assuming they map to different member disks).
March 19, 2012 15 92 48 Berkeley Fast File System (FFS) Assigns blocks to fixed disk locations, as physically close together as possible on a single disk, optimized for single-file-at-time access Apply it to NFS and the disk heads fly about madly Write Anywhere File Layout (WAFL) Writes blocks anywhere it finds convenient, close to the disk heads’ current positions The previous version of a changed block is not over-written (it’s either retained or marked free) WAFL then logically threads a single file’s current blocks by updating the block pointers – it’s easy to adjust the pointers in the “inode” The result: reduced disk seek/latency time* Figure 1 from http://www.netapp.com/tech_library/3002.html A tree of blocks
March 19, 2012
March 19, 2012 9 86 42 Unlike general purpose file systems, WAFL has an intimate understanding of its underlying physical disk configuration. WAFL caches write operations that come in from the network, and then optimizes by performing multiple write operations all together within the same RAID array stripe. The stripe is chosen based on its physical proximity to the location of the disk heads at the time of the operation. This behavior ensures that the single parity disk does not become a bottleneck within the system as it would typically do with a general purpose file system. It also allows WAFL to achieve excellent write performance, since the disk heads never have to seek very far to write client data. Fragmentation is also not a significant issue with WAFL, as data belonging to the same file is always written to adjacent locations within the stripe.
March 19, 2012 9 86 42 Unlike general purpose file systems, WAFL has an intimate understanding of its underlying physical disk configuration. WAFL caches write operations that come in from the network, and then optimizes by performing multiple write operations all together within the same RAID array stripe. The stripe is chosen based on its physical proximity to the location of the disk heads at the time of the operation. This behavior ensures that the single parity disk does not become a bottleneck within the system as it would typically do with a general purpose file system. It also allows WAFL to achieve excellent write performance, since the disk heads never have to seek very far to write client data. Fragmentation is also not a significant issue with WAFL, as data belonging to the same file is always written to adjacent locations within the stripe.
