[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] new command lacks lock
From: |
Ralph Corderoy |
Subject: |
Re: [Nmh-workers] new command lacks lock |
Date: |
Thu, 17 Oct 2013 16:02:13 +0100 |
Hi Ken,
> > A script that was using mark(1) was sluggish on a local-disk folder
> > with approx. 6,500 emails and many extra files after rmm, refile,
> > etc. Deleting those, or using the script on a directory with less
> > inodes, was a lot snappier.
>
> It would be nice to understand what was so sluggish; system call
> tracing would be interesting here. Sadly, I think we're limited by
> the operating system here in many cases; some Unix filesystems simply
> don't behave well when dealing with a lot of files in a single
> directory.
It's Linux with ext4 on a local SATA hard disk. Next time it's built up
enough to slug I'll have a look. `ls -f' wasn't slow so I suspect some
per-item overhead in nmh.
> It seems that this behavior is generally what you want...
Agreed. I wasn't trying to get it changed, just that its behaviour is
non-obvious and undocumented. Yes, I know, patches welcome. :-)
Cheers, Ralph.
- [Nmh-workers] new command lacks lock, Harvey Eneman, 2013/10/12
- Re: [Nmh-workers] new command lacks lock, Ken Hornstein, 2013/10/13
- Re: [Nmh-workers] new command lacks lock, epg, 2013/10/14
- Re: [Nmh-workers] new command lacks lock, Ken Hornstein, 2013/10/14
- Re: [Nmh-workers] new command lacks lock, Eric Gillespie, 2013/10/16
- Re: [Nmh-workers] new command lacks lock, Ken Hornstein, 2013/10/14
- Re: [Nmh-workers] new command lacks lock, Ralph Corderoy, 2013/10/17
- Re: [Nmh-workers] new command lacks lock, Ken Hornstein, 2013/10/17
- Re: [Nmh-workers] new command lacks lock,
Ralph Corderoy <=
- Re: [Nmh-workers] new command lacks lock, Ken Hornstein, 2013/10/17
- Re: [Nmh-workers] new command lacks lock, Ralph Corderoy, 2013/10/17
- Re: [Nmh-workers] new command lacks lock, Robert Elz, 2013/10/17
- Re: [Nmh-workers] new command lacks lock, Ralph Corderoy, 2013/10/17