Hi, We have a files implementation which wants to receive LAYOUTCOMMIT when a client is finished with a layout. It was my clear understanding from rfc5661 that we could expect this behavior. I would have no issue at all with allowing the implementation to indicate to clients that it doesn't care to or need to receive LAYOUTCOMMIT, as I believe David Noveck proposed. It creates a real problem if LAYOUTCOMMIT is simply rationalised out of the specification by filesystems which have other means to efficiently ensure semantics which may not be efficient or reasonable for ours. Matt ----- "Fred Isaman" <iisaman@xxxxxxxxxx> wrote: > >>> On 12/10/2010 03:22 AM, Fred Isaman wrote: > >>>> Since file does not need them, just turn them off for > >>>> the moment. ÂNon-file layouts will probably have to trigger them > in > >>>> some fashion at close. > >>>> > >>> > >>> Rrrr. Are we back to this argument. We stand down win an argument > >>> and 2 weeks later you are back on it has if we never talked about > it. > >>> > >>> NO!!! only "coherent clustered filesystems" do not need them. It > has > >>> nothing to do with layout type. A none-clustered aggregated > parallel > >>> filesystem will need them just the same as blocks and objects. > >>> > >>> AND THE STD DOES NOT GIVE YOU A CHOICE!!! > >> > >> You keep saying this, but just repeating it does not convince me. > >> Could you please take the time to explain *why* they are needed. -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
