Alexei Rodriguez wrote:
With a filer, the only option is RAID 4. Is there something in particular that would make RAID 4 a poor choice for this application?
When you say "faster, less secure", what aspect of operations are you looking at?
RAID 0. I know, I know, it sounds almost suicidal but as I said speed is more important in this instance than recovery. We'll be testing this 760 against an Auspex, which can be configured to use RAID 0, so I was wondering if the NetApps could also do this.
Its my feeling that testing this against the Auspex wouldn't be fair if NetApps is at RAID 4. We'll see if I'm wrong.
WAFL and RAID 4 are very tightly integrated. WAFL stands for "write anywhere file layout". Whenever you update file data you must also update the inode. On conventional filesystems the location of the inode is static. This can cause write performance problems because every time you update file data, you also have to update the inode. The data block and the block containing the inode might not be be on the same stripe. In a conventional RAID system, you end up updating the stripe with the inode (data and parity) and updating the stripe with the file data (data and parity).
WAFL, on the other hand, never overwrites an inode or a data block. WAFL always replaces an old block with a new one. The old block is freed and the new block is linked into the filesystem. To accomplish this, inodes are stored in a metafile rather than in fixed locations. So what does this buy you? When writing file data you are not tied to any particular block. Any free block is suitable. This means that WAFL can use whatever free blocks happen to be currently under the disk heads. WAFL doesn't waste a lot of time bouncing the disk heads between data blocks and fixed inode blocks.
WAFL also buffers up filesystem updates so that they can be scheduled in an orderly and efficient way. RAID 4 is built into WAFL, so WAFL itself manages the parity drives. WAFL writes a burst of updates to the same stripe and only hits the parity drive once. It can also localize its updates to nearby stripes so that the parity drive heads do not move much. This makes netapp write performance blazingly fast.
Read performance cannot be enhanced by this trick because you must always move the disk heads to wherever the data you need is located. To improve read performance, recently accessed filesystem blocks are cached in RAM. Often reads can be accomplished without hitting the disks.
-- Eric Hunter System Administrator
Gigaton.com, Inc. 1200 Brickell Ave. STE 680 Miami, FL 33131 Ph: +1 (305) 373 2002 Fax: +1 (305) 373 2034
eric@gigaton.com
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support