[Lustre-devel] SOM questions

[Vitaly Fertman]

On Jan 11, 2010, at 6:47 PM, Alex Zhuravlev wrote:

> I'd say we don't need DW at all.
>
> it's OST who knows whether attributes are stable (no pw locks and
> flush/commit is done, so i_blocks won't change till next open/write).

what do you mean stable? If you mean they are not going to change,
this is exactly what OST doesn't know because it doesn't know if file
is opened.

> I think in general the procedure to refresh SOM attributes could
> look like the following:
>
> 1) MDS gets GETATTR and finds the file hasn't been open for a period
>   it set special flag in GETATTR reply - say, REFRESH_SOM
> 2) client does regular enqueue/glimpse to get attributes from OST
> 3) if OST finds inode is stable (VBR version >= last_committed)
>   it set another special flag in reply - say, ATTR_STABLE
> 4) now, if client has REFRESH_SOME, ATTR_STABLE for all objects
>   *and* locks granted, then it can send aggregated attributes to
>   MDS to refresh SOM  attributes
> 5) if the file hasn't been open since that REFRESH SOM, attributes
>   can be set
>
> it looks quite simple and with very minimal changes to existing  
> protocol
> logic. I also think that following this we don't need dedicated IO  
> epoch
> notion and can use regular VBR version increasing on each open.

could you clarify how you can block IO from "lost" clients without
writing some id (VBR id?) to OST objects and not waiting for this
change to commit before updating MDS with new attributes?

--
Vitaly