I have a situation where I'm possibly going to create a virtual file system on FreeBSD, comprised entirely of nullfs mounts of selected "ordinary" dirs within my various ZFS datasets (and their snapshots). The tree will be created/maintained by a periodic script.

I want to use nullfs rather than symlinks because the dirs could be on any dataset in the pool, and it'll ensure that (almost) all commands are guaranteed to treat the virtual FS as a single file system/device, so there's less risk of accidents/omissions with commands that behave differently across mountpoints or traversals, and the virtual FS will be (almost) guaranteed to act as a single FS, avoiding user error.

A rough calculation says that there will be a lot of dirs mounted this way. I'm expecting thousands to tens of thousands, and perhaps a limit somewhere between 40k - 200k depending on future use of the server. I'd probably limit it to 150k initially to give margin for error, if FreeBSD can cope with that, but realistically I doubt it'll go over 50k - 80k.

My question is about the effects of doing this. I haven't read anything about mountpoint scaling. Is a very large mount table likely to slow the system negligibly or severely, and which if any sysctls need to be set to increase the default limits and allow this? In all, what are the practical limits and side-effects to expect, and any impressions about how severe or negligible?

The server is specced for heavy use (plenty of RAM, fast CPU, fast disk pool, good enterprise hardware etc) so physical resources per se shouldn't be an issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.