[SAGA-RG] missing(?) method reporting last modification time

[John Shalf]

For the async version of the SAGA interface, what consistency model to  
you propose for the modification time information?  POSIX semantics do  
not address this, which is precisely why POSIX is so damned slow on  
distributed/remote filesystems.  It seems we'd need to at least  
propose an unambiguous consistency model for the time-stamps and how  
this would interact with concurrent async read/write calls that might  
be in progress.

(just making the consistency model based on current state at the  
remote side is fine, but from the client side, you might end up with  
absurd situations when you do an async timestamp request concurrent  
with an async file open for example.)

-john

On May 29, 2009, at 6:15 AM, Thilo Kielmann wrote:
> Folks,
>
> within our group we are currently delving into issues with accessing
> remote file systems. What strikes us is that such access is SLOW.
> As such, it would be very beneficial if one could find out when (and
> thus whether) a remote file or directory has been modified.
>
> While returning this piece of information sounds to be "trivial", it  
> strikes
> us that the SAGA spec has no such call in the name space package  
> (where files
> reside).
>
> In POSIX terms, this is the info returned by the stat system call
> (see: man 2 stat), with the st_mtime parameter.
>
> In Java, files have a method lastmodified().
>
> Both POSIX and Java report the time in milliseconds since 01/01/1970  
> (epoch).
>
>
> Of course, it looks like nobody has ever been thinking about such a  
> use case,
> but here we are! Our feeling is that the last modification time is  
> very
> essential meta data about files, so such a call should certainly be  
> there.
> With our current problem certainly not being the only use case for  
> finding
> out how old/new a given file or directory is...
>
> Our favourite proposal is to add a method that returns the last  
> modification
> time to both ns_entry and ns_directory as this makes sense with  
> physical as
> well as with logical (replicated) files.
>
>
> Any reactions/objections ???
>
>
> Thilo Kielmann
> -- 
> Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/
> --
>  saga-rg mailing list
>  saga-rg at ogf.org
>  http://www.ogf.org/mailman/listinfo/saga-rg