On 09/14/2014 05:16 PM, Trond Myklebust wrote: <> > > 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. > Yes! which is why it sucks ;-) > 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. > "impossible to implement" without lo-segments yes. *With* lo-segments it is my opinion that it is possible. With the contraption of device_id per segment. But this argument is mute we both agree that in current code it is not needed. [ If at future time someone will want to implement lo-segments for Linux files layout, I think it could be a nice optimization, just as it is with objects and blocks. Imagine a most simple files MDS that wants to not create filehandles(files) on DSs that will not be reached. (Create on demand). In such case deleting the DS-files on truncate might make sense no? ] Xheers Boaz -- 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
