unlink performance
Matija Nalis
mnalis-ml at voyager.hr
Tue Aug 14 23:43:21 UTC 2007
On Tue, Aug 14, 2007 at 11:08:28AM -0700, Ryan Dooley wrote:
> I'm looking for clues about speeding up unlink performance. I have an
> ext3 file system (well, across several machines) that have a temp
> directory. The application needs to clean up the temp directory before
> the next run of the application begins and the engineers want to clean out
> this temp directory "quickly".
Depending on your usage (and not dependant of specifics of filesystem), you
might be able to get away with:
mv /path/to/temp /path/to/temp.old
mkdir /path/to/temp
rm -rf /path/to/temp.old &
as a workaround. in that way, the new run which fills the '/path/to/temp'
can commence practically without any delay even while old data is still
being removed, without any clash.
> The file system in question is mounted with noatime,nodiratime with the
> following filesystem features:
>
> has_journal, resize_inode, dir_index, filetype, needs_recovery, sparse_super and large_file
What is the journal size ? (echo 'stat <8>' | debugfs /dev/md0)
You can try increasing it. How much RAM is in the machine ?
> The operating system is Fedora Core 6 with fedora's 2.6.20-1.2933 kernel.
> The mounted file system is about 1.2TB in size and is a software raid-5
> over four, 7200 rpm SATA disks. The disks were formatted with all the
> defaults.
RAID5 would NOT be fastest choice for writes (including deletes), especially
depending on the stripe size, and is dependant on "mke2fs -E stride" option.
> Pre-loading the file system cache (a la "find /path/to/temp -type f -print
> >/dev/null") followed by an "rm -rf /path/to/temp" seems to be pretty
> speedy to me.
Then there is no problem, yes ? :)
--
Opinions above are GNU-copylefted.
More information about the Ext3-users
mailing list