Could this have anything to do with the SYNC problem that was brought to light in the past two weeks? Maybe AIX/jfs is doing dome additional processing in order to flush the disks. I know that ext3 can do write combining that may be driving down the "cost" of the SYNC.
I'm not saying that my bet isn't on the dumb application, but it's something to consider. Cheers, Eirc On 5/10/06, Jeremy Allison <[EMAIL PROTECTED]> wrote:
On Wed, May 10, 2006 at 01:14:08PM -0400, Claus Lund wrote: > > I agree that it's not a Samba logic problem ... more like a Samba porting > problem? > And I don't think we can just blame JFS2 and/or AIX either because deleting > files in that directory directly on the box or even through NFS is orders of > magnitudes faster (minutes vs days to delete all the files in a directory > with 150K files). But the nfs or local access isn't performing the same access pattern that Samba is by being driven by the client. I'm guessing that if you performed the same actions locally that the client is requesting Samba perform you'd get the same results (in fact you *must* - as all of Samba is userspace, there's no magic in what Samba is doing here - it's doing what the client requests from userspace). My money is still on the kernel, as driven in this access pattern. Now the access pattern may be insane, but that's not our fault :-). Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
-- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
