[Linux-cluster] RHEL4U5 GFS: 257, 000 small file creation and removal

[Robert Hurst]

That did the trick, thanks for the vote to make it "warm & fuzzy" for
us!   ;^)


On Tue, 2008-12-09 at 13:56 +0000, Steven Whitehouse wrote:

> Hi,
> 
> On Tue, 2008-12-09 at 08:57 -0500, Robert Hurst wrote:
> > A runaway application print job created this large number of
> > identically small files yesterday, which in turned caused mucho
> > problems for us trying to do a directory listing (ls) and removal
> > (rm).  Eventually, we had to fence the node that had incurred a system
> > load of over 800(!), and upon reboot, I removed the files using
> > something more GFS-friendly, i.e., find spool -name 'PRT_4*' -exec rm
> > -fv {} \;
> > 
> > Temporary print files are now being created and removed cleanly and
> > efficiently, as before.
> > 
> > But while that solved the cleanup, and even with umount / mount the
> > other 2 two nodes' GFS spool directory, we are still experiencing
> > latency when doing a simple ls in that directory -- not nearly as bad
> > before, but nonetheless a few seconds can go by just to print < 100
> > entries.  It is naturally concerning to us, because no other directory
> > in that same GFS filesystem (or any other) is giving us any such
> > latency issues.
> > 
> > The spool directory entry itself grew to 64kb from its usual 2kb, to
> > accommodate all those prior filenames ... is that something that is
> > required to be re-mkdir'ed in order to avoid this GFS latency?
> > 
> Yes, thats probably the best solution. GFS directories do not shrink
> when entries are removed. There is a plan to fix this in GFS2 at some
> stage, but at the moment it shares this trait I'm afraid,
> 
> Steve.
> 
> 
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20081210/3995aaa4/attachment.htm>