> -----Original Message----- > From: linux-cluster-bounces@xxxxxxxxxx [mailto:linux-cluster-bounces@xxxxxxxxxx] > On Behalf Of Peter Schobel > Sent: Friday, July 10, 2009 11:49 AM > To: linux clustering > Subject: Re: rm -r on gfs2 filesystem is very slow > > This performance problem exhibits itself even when using a single > node. Writing to the filesystem seems to work fine. The time to do a > cp -r dir /gfs/dir is very comparable to writing to local disk > however, rm -r /gfs/dir takes considerably longer than it does on > local disk. I am guessing this is a feature of dlm checking for a lock > on each individual file but I'm not sure. We had similar results on GFS1, and obtained a large improvement by increasing demote_secs in some cases. I haven't tried GFS2 yet, and don't know if would do the same. One of our GFS1 filesystems contains files that don't normally live longer than an hour. They are created, expire after an hour, and get reaped (rm'ed) within 2 hours. Settings demote_secs to 7200 for this filesystem made a huge difference, because (as I understand it) it increased the likelihood that a lock would still be held on the inode by the time it was to be removed. -Jeff -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
