Date: Tue, 18 Dec 2001 22:23:35 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: rohit@gojuryu.com Cc: freebsd-fs@freebsd.org Subject: Re: upper limit on # of vnops? Message-ID: <3C203267.43543107@mindspring.com> References: <20011219032759.23F5136F9@sitemail.everyone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Rohit Grover wrote: > I am using Freebsd4.3-RELEASE and wish to add a few vnode ops. > Is there an upper limit on the number of vnode ops supported > by the VFS layer in Freebsd? No. But there are a number of artificial constraints on when and how they may be added. > I am having some trouble going beyond a certain small number of > new operations. Any help would be appreciated. Most likely, you do not need to add operations, and you should be hooking your changes into fcntl(), etc.. In the unlikely event that you need to add some ops, you should be aware of the artificial limitations: 1) When the vnode_if.h and vnode_if.c code is generated from /sys/kern/vnode_if.src by /sys/kern/vnode_if.pl, the number of NOPs permitted is fixed, by virtue of the fixed size VOP descriptor array. 2) When the VFS system is first initialized, it takes an existing filesystem instance, and refactors it in order to get the total number of VOPs. This is arguably more correct than what it did perviously (counted the VOPs in the FFS code, for a mandatory instance of FFS), but the limit is real, and can't be exceeded. Basically, this adds some recompilation requirements that are much less obvious than they should be, if you are using modification of /sys/kern/vnode_if.src to add the new VOPs. The best suggestion, if you are using this method, is to delete and recreate the compilation files, rather than expecting the dependencies to work if you add VOPs. 3) You can not add VOPs to the table at run time. The best you can currently do is to replace placeholder VOPs with new VOPs. If you have placeholder VOPs, and you do this (see the end of the VOP descriptor array in the generated vnode_if.c in the kernel compilation directory), you are limited to the number of placeholders that exist. If you look at the system call extension code, you will see that it has this same limitation. 4) If you want to correct this, you will need to refactor all existing FS instances when you add a VOP (or VOPs). To do this, you will need to recreate the instance structures for the existing FS instances, and you will need to replace/extend the existing VOP list, as it is in vnode_if.c. The vnode_if.h changes, which provide the wrappers are less important (you can manually add those to only the code that uses them). The main thing you will have to do is to ensure that all references to the generated list are by pointer, and then reallocate and copy the list, and then add your VOPs to the end of the list, following extension. Since VOP calls are made through this list, you will need to take the FS instance structures, which are allocated at mount time, and reallocate them, copying the old in, and maintaining defaults. 5) Because of PHK's "default vops" stuff, you will need to refactor the instances, as well, rather than simply copying them, so that the correct defaults are maintained; in the original design, there was no such thing as "default vops", and such refactoring would not have been necessary (though you would still have to reallocate and do the prefix copy of the previous VOPs, if the VOP vector list changed; but the default of "not supported" would have been correct, particularly for intermediate stacking layers, where it would become a "pass through"). 6) If you intend to support stacking, you will have to refactor the stacks, as well. This may be tricky. The correct thing to do when creating a stack is to push all NOP layers down in the instance version, which would (effectively) cut the intermediate layer transitions out of the assembled call graph. Effectively, this means that when you add VOPs, particularly VOPs for which there are non-pass-through defaults (another thing that interferes with stacking, as in the original design, all defaults were pass through), you will need to reconstruct the list. 7) For most of the above reasons, that means that when you are adding VOPs at runtime, you will want to complete refactor all existing mount instances, such as they are (I say it this way because, though it is unlikely, if you were to be using one of the proxy layers -- either network or user space -- that UCLA CS students did in John Heidemann's classes, then you would find it impossible, since you can not control the defaults on the other side of the proxy... consider a proxy from a local consume that knows about the new VOP to a remote stacking layer that doesn't, back to a local media FS that does, and the fact that you want the VOP to go all the way through and back, without harm, but it is out of range of the decriptor list on the remote node because of the "default vops" handling). All in all, it would be much, much easier for you if you did one of: A) Use fcntl() in the FS, instead, and don't invent new VOPs. OR: B) Add the VOPs to the /sys/kern/vnode_if.src, and totally recreate the compilation directory, in order that your VOPs will be apriori known to the system. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C203267.43543107>