On 2010-10-13 17:20, Trond Myklebust wrote: > On Wed, 2010-10-13 at 17:13 -0400, Benny Halevy wrote: >> On 2010-10-13 16:54, Trond Myklebust wrote: >>> On Wed, 2010-10-13 at 16:34 -0400, Benny Halevy wrote: >>>> On 2010-10-13 14:03, Fred Isaman wrote: >>>>> On Wed, Sep 29, 2010 at 7:10 AM, Benny Halevy <bhalevy@xxxxxxxxxxx> wrote: >>>>>> To initialize all values to zero, in case the server or protocol version >>>>>> do no support particular attributes. >>>>> >>>>> Sorry for the delayed response, but... >>>>> >>>>> Zero is not an appropriate default for many of the values. Further, >>>>> decode_fsinfo sets a default for each value, even in cases where the >>>>> server or protocol version do not support particular attributes. So >>>>> this patch seems to server no purpose. >>>> >>>> Note that nfs_probe_fsinfo is called also for nfs version 2 and 3 >>>> and these don't know anything about nfsv4.1 attributes so they can't >>>> cannot explicitly set them to any default value. >>> >>> Err... Why would we care? Under exactly what circumstances would we want >>> generic code to be processing fsinfo attributes that are specific only >>> to NFSv4.1? >>> >>> Trond >> >> Originally, set_pnfs_layoutdriver, was called only for nfsv4.1 >> but we changed it to always be called in nfs_server_set_fsinfo() > > So it relies on a flag in the fsinfo structure to tell it that this is a > pNFS-capable server? That's fine, but in that case, you should perhaps > explicitly initialise that flag to the non-pNFS capable value in the > generic code. > We shouldn't need to zero out the entire structure. OK. That's possible. Benny > > Cheers > Trond -- 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
