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

[Thilo Kielmann]

Well, the intended semantics was reporting the remote state.
Of course, in the presence of asynchronous operations (or simply operations
done by other, e.g. non-SAGA,  processes), all kinds of problems and race 
conditions can occur. But that's just plain normal. 

I see nothing special with tme stamps, that we would not have with anything
else we already have.

Thilo

On Fri, May 29, 2009 at 06:39:08AM -0700, John Shalf wrote:
> Cc: saga-rg at ogf.org
> From: John Shalf <JShalf at lbl.gov>
> To: Thilo Kielmann <kielmann at cs.vu.nl>
> Subject: Re: [SAGA-RG] missing(?) method reporting last modification time
> 
> 
> It just makes problems with an undefined consistency model clearer  
> because ordering of requests may result in incorrect timestamps.  The  
> problem is more difficult when dealing with timestamps because that  
> hits the metadata server, which is a different data path than data  
> storage. Users will assume POSIX-like consistency where
> 	a=check_timestamp(file foo)
> 	write(file foo)
> 	b=check _timestamp(file foo)
> that b will always be greater than a.  For remote connections, this is  
> more difficult to guarantee unless you are explicit about the  
> underlying consistency model.  Are you going to claim POSIX  
> consistency?  If so, then it doesn't have anything to say about the  
> async case.
> 
> I brought this up years ago, but reading the current spec I don't see  
> that info. I'm not sure if it has been fully addressed.  It will be  
> easier to end up with absurd or seemingly incorrect situations with  
> relying on timestamp data.
> 
> -john
> 
> On May 29, 2009, at 6:29 AM, Thilo Kielmann wrote:
> >John,
> >
> >what would be the special thing with a timestamp and everything else,
> >like file size, content, permissions... that we all have already?
> >
> >Thilo
> >
> >On Fri, May 29, 2009 at 06:21:40AM -0700, John Shalf wrote:
> >>Cc: saga-rg at ogf.org
> >>From: John Shalf <jshalf at lbl.gov>
> >>To: Thilo Kielmann <kielmann at cs.vu.nl>
> >>Subject: Re: [SAGA-RG] missing(?) method reporting last  
> >>modification time
> >>
> >>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
> >>
> >
> >
> >
> >-- 
> >Thilo Kielmann                                 
> >http://www.cs.vu.nl/~kielmann/
> 



-- 
Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/