> It would be really interesting how long the described backup takes when the gfs2 filesystem is mounted exclusively on one node without locking.
The 2 million inode system backs up in about 30 minutes when mounted lock_nolock (0 file incremental backup using bacula)
> For me it looks like you're facing a similar problem with gfs2 that has been worked around with gfs by introducing the glock_purge functionality that leads to a much smaller glock->dlm->hashtable and makes backups and the like much faster.
Quite likely. Backup performance under GFS2 is slightly worse than with GFS. "ls -l" in a directory is _significantly_ worse and can take up to 4 minutes for a directory with 4000 files onboard (Remember: This is with the GFS2 filesystem mounted lock_dlm on one node only!)
Compounding matters, we have a network /home - mounted on the fileservers and NFSv3 exported to ~150 RHEL5 desktops (Lots of small files, LOTS of random access).
KDE, Openoffice, Thunderbird, Mozilla are all pretty lock/cachefile happy and hit the network /home export fairly hard, so when there's a performance issue the users get pretty noisy.
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
