ryan.bloghorn.com

username:
password:

Recent Comments:

My Links:

6/13/2006 11:12:38 AM

problem solved.

it was simple.

no more traversing a directory to see if files are still growing.

---
chop(my $rc = `du -s $dir`);
my ($size1, $trash1) = split /\t/, $rc, 2;

sleep(1);

chop($rc = `du -s $dir`);
my ($size2, $trash2) = split /\t/, $rc, 2;

return 0 if $size1 != $size2;
return 1;
---

eesh.  du.  whodathunkit?

Permalink  - Comment [3]

Submitted by Chris at 6/13/2006 2:18:29 PM
    Depending on file-count/levels-of-recursion in the directory, "du" can be extremely resource-intensive and eat lots of i/o. Also, "du"'s output will not vary if directories or zero-length files are being created. YMMV.
Submitted by ryan at 6/13/2006 3:16:20 PM
    understood.

    the script in question will only work with stuff on the local filesystem.

    also - 90% of the time it will be dealing with single files. the other 10% will be single directories, with only probably 1% containing a subdirectory.

    no files will be zero-length... and there shouldn't be any empty directories.

    still, i'll toss it over to the QA peeps and see if it bounces back over to me. :)

    thanks for the heads up Chris.
Submitted by Chris at 6/13/2006 5:13:05 PM
    Hey, it was a learning experience for me. I knew the first part (du = i/o), but only suspected the second half. I tested it to know for sure. I can't say how many times I've ground production systems to a standstill by using du to try to assess storage utilization problems (which user is hogging the space, and with what). Too bad there's no "nice" for i/o.
Name: Url:
Confirm: