From: Noveck, Dave (dave.noveck@netapp.com)
Date: 03/22/00-08:19:26 AM Z
Message-ID: <F6C5585BF0CED311B58D009027C2299C47C036@tahoe.corp.netapp.com> From: "Noveck, Dave" <dave.noveck@netapp.com> Subject: RE: Compound operations : NFS kernel support Date: Wed, 22 Mar 2000 06:19:26 -0800 kvs sivak wrote: > We are trying to implement NFS v4 support in Linux > Kernel 2.2. > It is needed that the VFS interface be coded to > support any required file system in Linux.Since the > VFS looks at each operation as an independent one > there seems to be no advantage in using Compound > except in adding the extra processing required. I don't know the details of the Linux VFS but there may be cases in which you will want to compound GETATTR with other operations, such as OPEN. When opening a file you are supposed to clear your data cache if the file has been modified since the last time you opened it. Doing a GETATTR compounded with the OPEN is probably the best way to do that. In cases where your VFS structure means that the information it would be convenient to get with COMPOUND is not required by the current operation, you can still use caching to avoid RPC's. If you put the results of a GETATTR compounded with another request in you attribute cache, it will be available when OS code, through the VFS, decides to ask for it, avoiding an RPC at that point. Depending on the kinds of environments you are targetting, you could extend this to other cases in which the need for the attributes is probable but not certain. You could always add GETATTR to LOOKUP on the grounds that it adds very little cost and will often be required. You could also add READ to OPEN for read to get the first block of data and cache it. There are lots of possibilities. Some of them may even be desirable :-) When latency is high, it might even be useful to combine operations for unrelated files with an RPC tat you are doing anyway. For example, attribute and name cache entries that are being used but are soon to time out, might be revalidated by doing GETATTR's compounded to a totally unrelated RPC. > > for example the namei opreation looks up directories > at only one level. there is no multi-component > lookup.This would make it impossoible to use the > multi-component lookup of NFSv4.Thus the kernel would > request lookups only for a single component and there > is no way to determine a full pathname that may be > sent to the NFS server for multi-component lookup. I don't see how you could use multi-component lookup. > similarly for other procedures too. For multi-component lookup, the V4 client code has no way of knowing or effectively guessing what will be needed next. In cases in which you can make a good guess it may be possible to do operations in advance, as long as those only interrogate file system state. > Is this understanding of ours correct ? > Are there any other means by which compound opreations > can be used advantageously ? I believe there are but this is just speculation. I think everyone is very interested to find out how useful COMPOUND turns out to be in practice.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:09 AM Z CST