That's not it. The RAID-4 has nothing to do with this behavior. The=20 behavior described is symptomatic of a WAFL filesystem with an=20 oversubscribed cache. Since WAFL will never overwrite an existing=20 block, but simply append writes to the next available slot in the free=20= block list, the tablespace described will effectively be located=20 half-and-half on two different filesystem regions. If there was enough (read: a lot) of cache in the filer, this problem=20 would be mitigated, since all of the recently modified blocks would be=20= in cache, but overall this is definitely the worst-case situation for a=20= Netapp. Thanks, Matt -- Matthew Zito GridApp Systems Email: mzito@xxxxxxxxxxx Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com On Aug 4, 2004, at 7:54 PM, Mogens N=F8rgaard wrote: > I like the NetApp guys, etc. But it is really RAID-4 (no kidding), so > perhaps that might explain one or two things? Just guessing... > > Mogens > ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------