Re: No space left on device (28) but device is NOT full!
On Tue, Nov 05, 2013 at 04:54:19PM +0000, Jonathan Dowland wrote:
> The binary size effects the initial load-up time which, for small
> numbers of files/short execution times, may be the lions share of
> the total execution time. However as you point out, for orders of
> magnitute like 500,000; it's dwarfed by the algorithm.
I agree with you. I assumed if OP needed to remove all that popcon logs
- there would be large amount of those files.
> I'm quite amazed how much faster your perl implementation was. I
> can only imagine that nobody has ever been troubled by find's
> performance enough to work on it. This points to find not taking
> advantage of parallelism (and also to potential improvements in
> speed even for your perl implementation).
Well, the primary usage of find is to find files, not to delete them.
And find shows reasonable speed if you need to delete medium amount of
files.
Besides, deleting that amount of files is a rare unusual task, so using
custom tools to do it is only fitting. Half-million is a small amount.
Once I had to purge ~200m files - now that was slow.
> > Basically, the difference is in the fact that find uses fstatat64
> > syscall for each file, and this perl one-liner uses lstat64 and stat64
> > syscalls. Use strace to check it in your environment. On another OS
> > results could be different.
>
> So you believe the discrepancy is entirely down to the difference
> between fstat64 and lstat/stat64? I find that hard to believe. I
> suspect find is just not very efficient.
I never bothered to see find source to check how they do it.
Or kernel source for the implementation of these syscalls.
Still, the fact stands - both find and one-liner use unlink (find uses
unlink64, but that should not be relevant), one-liner does double amount
of stat syscalls compared to the find, yet it's faster.
Probably C implementation would be even more faster, but I'm to lazy to
do it.
Reco
Reply to: