Lori,
From what I recall about the way WAFL scans, and what I can infer from that, I don't believe that a fragmented filesystem would make the scan take any longer.
If I'm correct in my thinking, it scans the blocks contiguously and determines how many blocks that belong together (for files) are actually in the same place. The ratio is where the index comes from...
Glenn
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Lori Barfield Sent: Wednesday, March 08, 2006 4:12 PM To: philip.boyle@eircom.net Cc: toasters@mathworks.com Subject: Re: wafl scan reallocate
another data point for the group. the previous scan was run on our busiest filer (an fas270); below is the impact of doing a scan on our largest user data filer.
this filer is an fas270 with one ds14. there are 11 disks in the raid group (and aggregate). the volume is only 3-4 months old, but storage utilization vascillates wildly on this puppy but it usually operates above 95% and has run out of space several times in its young life. we are not snapmirroring. i think we are currently using 995gb (.97tb) on the volume including snap, but someone should check my calculation (df below).
i started the scan at the beginning of lunchtime, when the filer happened to be nearly quiescent. it took 54 minutes. it killed my cache but only sucked up 7-12% of the cpu.
i imagine a low fragmentation condition would make a scan less taxing.
...lori
/vol/vol1/ 1132462080KB 917995432KB 214466648KB 81% /vol/vol1/ /vol/vol1/.snapshot 125829120KB 153743936KB 0KB 122% /vol/vol1/.snap shot
cartman*> sysstat 1 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 1% 0 0 0 0 0 0 0 0 0
60
1% 0 0 0 0 0 0 0 0 0
60
1% 0 0 0 0 0 0 0 0 0
60
1% 0 0 0 0 0 0 0 0 0
60
1% 0 0 0 0 0 0 0 0 0
60
4% 0 0 0 0 0 607 563 0 0
60
cartman*> wafl scan measure_layout vol1 cartman*> Wed Mar 8 12:15:05 PST [wafl.scan.start:info]: Starting WAFL layout measurement on volume vol1.
cartman*> sysstat 1 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 8% 0 0 0 0 0 583 0 0 0 15 10% 0 0 0 0 0 1168 572 0 0 15 7% 0 0 0 0 0 636 0 0 0 15 8% 0 0 0 0 0 648 0 0 0 15 8% 0 0 0 0 0 632 0 0 0 15 8% 0 0 0 0 0 660 0 0 0 15 7% 0 0 0 0 0 636 0 0 0 15 9% 0 0 0 0 0 696 0 0 0 15 8% 0 0 0 0 0 696 0 0 0 15 12% 0 0 0 0 0 844 0 0 0 15 7% 0 0 0 0 0 668 0 0 0 16
CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 7% 0 0 0 0 0 592 0 0 0 4 8% 0 0 0 1 0 736 0 0 0 4 11% 0 0 0 0 0 756 0 0 0 4 10% 0 0 0 0 0 864 0 0 0 4 11% 0 0 0 0 0 920 0 0 0 4 8% 0 0 0 0 0 644 0 0 0 4
cartman*> Wed Mar 8 13:09:00 PST [wafl.scan.layout.advise:info]: WAFL layout ratio for volume vol1 is 1.22. A ratio of 1 is optimal. Based on your free space, 3.94 is expected.
On 3/8/06, Glenn Walker ggwalker@mindspring.com wrote:
Lori,
From what I recall about the way WAFL scans, and what I can infer from that, I don't believe that a fragmented filesystem would make the scan take any longer.
If I'm correct in my thinking, it scans the blocks contiguously and determines how many blocks that belong together (for files) are actually in the same place. The ratio is where the index comes from...
thanks, glen. if it's that simple then i wonder what it's doing with the "free space" factor.
...lori