Wafl Overview

WAFL Overview
NetApp Spotlight Series
More Info
WAFL: Write Anywhere File Layout

Filesystem for Improved Productivity
Berkeley Fast File System/Veritas File System/NTFS/etc. Writes to pre-allocated locations (data vs. metadata)
...
WAFL No pre-allocated locations (data and metadata blocks are treated equally). Writes go to nearest available free block.
1-2 MB Cylinders
...
Writing to nearest available free block reduces disk seeking (the #1 performance challenge when using disks).
2008 NetApp. All rights reserved. 2
Write Anywhere? Why do we do this?

WAFL == Write Anywhere File Layout Write anywhere does not mean that we literally write anywhere, to just any random block.
Write anywhere means that we can write anywhere, so we get to choose where we write.
And we choose carefully are efficiently.
2008 NetApp. All rights reserved.
WAFL Architecture Overview
WAFL uses integrated RAID4

RAID4 is similar to better known RAID5: RAID5: parity is distributed across all disks in the RAID group RAID4: parity is contained in a single disk in the RAID group Tradeoffs with the single parity disk RAID4 model: CON: The parity disk becomes the hot spot or bottleneck in the RAID group, due to intensive XOR parity calculations on it.
PRO: The RAID group can be instantly expanded by adding (pre-zeroed) data disks, because no parity re-calculation occurs.
WAFL eliminates the parity disk bottleneck

WAFL overcomes the classic parity disk bottleneck issue, by the use of flexible write allocation policies:
Writes any filesystem block to any disk location (data and meta data)*
New data does not overwrite old data
Allocates disk space for many client-write operations at once in a single new RAID-stripe write (no parity re-calculations)
Writes to stripes that are near each other Writes blocks to disk in any order
* except root inode

Result: Minimal seeks and no bottleneck

RAID4 with Typical File System
RAID4 with WAFL
Requests are scattered across the disks, causing the parity disk to seek excessively
WAFL writes blocks to stripes near each other, eliminating long seeks on the parity disk.
WAFL Combined with NVRAM
WAFL uses NVRAM consistency points (NetApps flavor of journalling), thus assuring filesystem integrity and fast reboots. CP flush to disk occurs once every 10 seconds or when NVRAM reaches half full. NVRAM placement is at the file system operation level, not at the (more typical) block level. This assures self-consistent CP flushes to disk. No fsck!
NVRAM placement is key!

General-purpose NV-RAM
NetApp NV-RAM
File System
TCP/ or UDP/IP
NFS or CIFS Semantic Write Alloc File System
TCP/ or UDP/IP
NFS or CIFS
Semantic Write Alloc
NVRAM
Disk Driver
NVRAM
Disk Driver
NVRAM safe-stores the disk blocks

NVRAM safe-stores the FS operation

9
NVRAM and memory key points

Main memory is the write cache The NVRAM is not the write cache It is a redo log Once written, we never even look at it again Unless a controller fault occurs before a CP is complete
and then we redo the operations in it
NVRAM-limited performance is a myth Write throughput is limited by the disks or the controller Redo-logging is very space efficient Record only changed data Big win for small writes
10
Seek Example in a SAN environment

Assume 4K disk blocks, 2.5 msec for one seek+rotate, and an ideal 200MB/sec FC path.
200MB/sec FC bandwidth x .0025sec = .5MB worth of data blocks not sent on the channel during that seek. .5MB x 1 block/4KB = 128 blocks not sent Therefore a 2.5ms seek for just 1 block equates to a 128 block penalty
Conclusion: one seek every 128 blocks or less ( ~1%) wastes at least half of your FC bandwidth!
128 blocks
(seek 1 block)
128 blocks
(seek 1 block)
11
The Protocol Overhead issue
Isnt NAS slower than local disk?

Yes, we have TCP/IP overhead. Yes, we have double-buffering overhead. Yes, we might well have <obscure performance gotcha>.
Despite all that, we're able to improve performance, even

with databases (now over 40% of NetApp customer base). Clearly, we're doing *something* sufficiently right to make up for the overhead.
12
The Protocol Overhead issue

Keep the timing in perspective with todays CPU speeds!
TCP/IP might seem to be a massive overhead, but passing
packets up and down the stack turn out only to consume

microseconds per request.
(For example: 1Ghz CPU speed == 1 ____second clock cycle. So 1000 extra nanosecond clock cycle.
CPU cycles for TCP stack = 1000x1ns = 1 microsecond)
Eliminating head seeks, which WAFL does better than any other file system thanks to its full integration with RAID,
TCP over head
saves whole milliseconds, eg, a 1000x savings.
128 blocks
(seek 1 block)
128 blocks
(seek 1 block)
TCP overhead is small by comparison

Superior performance vs. Competition
14
Summary
WAFL extracts more ops/sec and lowest latency from a single drive due to minimum seeks. This equates to faster overall performance WAFLs anywhere property makes NetApps RAID-4 the performance and scalability winner. Fastest File System in the world with RAID enabled
15

Wafl Overview

Uploaded by

Copyright:

Available Formats

Wafl Overview

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Wafl Overview

Uploaded by

Copyright:

Available Formats

WAFL Overview

NetApp Spotlight Series

WAFL: Write Anywhere File Layout

Write Anywhere? Why do we do this?

And we choose carefully are efficiently.

2008 NetApp. All rights reserved.

WAFL Architecture Overview

2008 NetApp. All rights reserved.

WAFL uses integrated RAID4

2008 NetApp. All rights reserved.

WAFL eliminates the parity disk bottleneck

* except root inode

Result: Minimal seeks and no bottleneck

RAID4 with WAFL

2008 NetApp. All rights reserved.

WAFL Combined with NVRAM

2008 NetApp. All rights reserved.

NVRAM placement is key!

Semantic Write Alloc

NVRAM safe-stores the disk blocks

NVRAM safe-stores the FS operation

NVRAM and memory key points

2008 NetApp. All rights reserved.

Seek Example in a SAN environment

2008 NetApp. All rights reserved.

The Protocol Overhead issue

Isnt NAS slower than local disk?

Despite all that, we're able to improve performance, even

2008 NetApp. All rights reserved.

The Protocol Overhead issue

packets up and down the stack turn out only to consume

CPU cycles for TCP stack = 1000x1ns = 1 microsecond)

saves whole milliseconds, eg, a 1000x savings.

TCP overhead is small by comparison

Superior performance vs. Competition

2008 NetApp. All rights reserved.

2008 NetApp. All rights reserved.

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.