On Sun, Sep 14, 2014 at 9:51 AM, Boaz Harrosh <boaz@xxxxxxxxxxxxx> wrote: > On 09/14/2014 04:24 PM, Trond Myklebust wrote: >> On Sun, Sep 14, 2014 at 6:55 AM, Boaz Harrosh <openosd@xxxxxxxxx> wrote: > <> >> >> No Boaz. I mean that it is utterly pointless and stupid to return a >> layout that doesn't preallocate any resources when it isn't necessary >> to do so. >> > > "preallocate any resources" where? at the client it might not but the server > might have allocated resources per lo-segment. > For example a CEPH server allocates a device_id per file-lo-segment. If you > lo_return a truncated segment it might be able to free that device_id. > There is no requirement anywhere in RFC5661 to state that a truncate must be prefixed by a layout return. Not in section 12 (Parallel NFS) nor in section 13 (NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type), nor in the ERRATA. Existing pNFS files servers (i.e. NetApp) don't need it either. If a future CEPH server wants to add its own requirements, then it is free to issue a layoutrecall. However my understanding from conversations with Matt (the Ganesha release notes appear to confirm) was that the CRUSH algorithm is pretty much impossible to implement as a files layout type, so I'm confused as to why it would be a problem in the first place. -- 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
