summaryrefslogtreecommitdiffstats
path: root/etc/mtree/BSD.root.dist
diff options
context:
space:
mode:
authordillon <dillon@FreeBSD.org>2001-10-01 04:33:35 +0000
committerdillon <dillon@FreeBSD.org>2001-10-01 04:33:35 +0000
commit5a5b9f79f48be499ceca11f3d54c0525935b9ac1 (patch)
tree24142bf3c28ad5430fe7af0d88da2999098b7f21 /etc/mtree/BSD.root.dist
parent86409d0972b660f68712b2324920bd859a72cf72 (diff)
downloadFreeBSD-src-5a5b9f79f48be499ceca11f3d54c0525935b9ac1.zip
FreeBSD-src-5a5b9f79f48be499ceca11f3d54c0525935b9ac1.tar.gz
After extensive testing it has been determined that adding complexity
to avoid removing higher level directory vnodes from the namecache has no perceivable effect and will be removed. This is especially true when vmiodirenable is turned on, which it is by default now. ( vmiodirenable makes a huge difference in directory caching ). The vfs.vmiodirenable and vfs.nameileafonly sysctls have been left in to allow further testing, but I expect to rip out vfs.nameileafonly soon too. I have also determined through testing that the real problem with numvnodes getting too large is due to the VM Page cache preventing the vnode from being reclaimed. The directory stuff made only a tiny dent relative to Poul's original code, enough so that some tests succeeded. But tests with several million small files show that the bigger problem is the VM Page cache. This will have to be addressed by a future commit. MFC after: 3 days
Diffstat (limited to 'etc/mtree/BSD.root.dist')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud