On 7/22/2011 6:10 PM, Dave Chinner wrote:
> On Fri, Jul 22, 2011 at 01:05:14PM -0500, Stan Hoeppner wrote:
>> I've never used a NetApp filer myself. However, that said, I would
>> assume that WAFL is only in play for NFS/CIFS transactions since WAFL is
>> itself a filesystem.
> Netapp's website is busted, so here's a cached link:
This is interesting:
The author implemented WAFL in two layers. The bottom layer handles
block stuff including volume management, dedup, snapshots, etc, and the
top layer functions as multiple file systems, amongst other duties.
> If you can be bothered trolling for that entire series of blog posts
> in the google cache, it's probably a good idea so you can get a
> basic understanding of what WAFL actually is.
It's never a bother to learn something new. :)
>> When exposing LUNs from the same filer to FC and iSCSI hosts I would
>> assume the filer acts just as any other SAN controller would.
> It has it's own quirks, just like any other FC attached RAID array...
>> In this case I would think you'd probably still want to align your
>> XFS filesystem to the underlying RAID stripe from which the LUN
>> was carved.
> Which actually matters very little when WAFL between the FS and the
> disk because WAFL uses copy-on-write and stages all it's writes
> through NVRAM and so you've got no idea what the alignment of any
> given address in the filesystem maps to, anyway.
Is the NetApp FC/iSCSI attachment performance still competitive for
large file/streaming IO, given that one can't optimize XFS stripe
alignment, and with no indication of where the file fragments are
actually written on the media? Or does it lag behind something like a
roughly equivalent class Infinite Storage array, or IBM DS?