> 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
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 10:20:56 EST