OpenSolaris

Printable Version Enter a New Search
Bug ID 6499704
Synopsis statvfs64 too slow with logging UFS
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kernel:ufs
Keywords delete | df | rtiq_regression | statvfs | ufs-cleanup | ufs_thread_delete | ufs_thread_run
Responsible Engineer Viswanathan Kannappan
Reported Against snv_82
Duplicate Of
Introduced In solaris_nevada
Commit to Fix snv_85
Fixed In snv_85
Release Fixed solaris_nevada(snv_85) , solaris_10u6(s10u6_01) (Bug ID:2161079)
Related Bugs 6251659 , 6302747 , 6447955 , 6660398 , 5012326
Submit Date 1-December-2006
Last Update Date 27-May-2008
Description
statvfs (statvfs64) is unacceptably slow while large files are beeing freed in the background on logging UFS.

Tests I've performed on a modest x86 system shows df hanging in statvfs64 for around 15 seconds after deleting some large files while UFS is freeing the blocks.

If I mount the filesystem "nologging", it takes just fractions of a second.

My tests were performed on a simple 40G UFS filesystem mounted on /mnt:
---
cd /mnt
mkfile 5g a b c
lockfs -f /mnt
rm a b c
---

In another window I ran "truss df -D /mnt".

Before the rm:

spiff:~ (361)> truss -D df /mnt
...
 0.0004 resolvepath("/mnt", "/mnt", 1024)               = 4
 0.0003 statvfs64("/mnt", 0x0804725C)                   = 0
...

This statvfs64 took just 300µs.

After the rm:

spiff:~ (362)> truss -D df /mnt
...
 0.0003 resolvepath("/mnt", "/mnt", 1024)               = 4
14.9443 statvfs64("/mnt", 0x0804725C)                   = 0
...

This statvfs64 took almost 15 seconds.
Work Around
N/A
Comments
N/A