Re: [PATCH 8/9] pnfs/blocklayout: return layouts on setattr

[Boaz Harrosh <boaz@plexistor.com>]

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