On Tue, 27 Nov 2012, Sam Lang wrote:
Hi Noah,
I was able to reproduce your issue with a similar test using the fuse client
and the clock_offset option for the mds. This is what I see happening:
clientA's clock is a few seconds behind the mds clock
clientA creates the file
- the
On Tuesday, November 27, 2012 at 8:45 AM, Sam Lang wrote:
Hi Noah,
I was able to reproduce your issue with a similar test using the fuse
client and the clock_offset option for the mds. This is what I see
happening:
clientA's clock is a few seconds behind the mds clock
clientA
On Nov 27, 2012, at 9:03 AM, Sage Weil s...@inktank.com wrote:
On Tue, 27 Nov 2012, Sam Lang wrote:
3. When a client acquires the cap for a file, have the mds provide its
current
time as well. As the client updates the mtime, it uses the timestamp
provided
by the mds and the time
On 11/27/2012 11:07 AM, Gregory Farnum wrote:
On Tuesday, November 27, 2012 at 8:45 AM, Sam Lang wrote:
Hi Noah,
I was able to reproduce your issue with a similar test using the fuse
client and the clock_offset option for the mds. This is what I see
happening:
clientA's clock is a few
On 11/27/2012 11:03 AM, Sage Weil wrote:
On Tue, 27 Nov 2012, Sam Lang wrote:
Hi Noah,
I was able to reproduce your issue with a similar test using the fuse client
and the clock_offset option for the mds. This is what I see happening:
clientA's clock is a few seconds behind the mds clock
On Tue, 27 Nov 2012, David Zafman wrote:
On Nov 27, 2012, at 9:03 AM, Sage Weil s...@inktank.com wrote:
On Tue, 27 Nov 2012, Sam Lang wrote:
3. When a client acquires the cap for a file, have the mds provide its
current
time as well. As the client updates the mtime, it uses the
On 11/27/2012 12:01 PM, Sage Weil wrote:
On Tue, 27 Nov 2012, David Zafman wrote:
On Nov 27, 2012, at 9:03 AM, Sage Weil s...@inktank.com wrote:
On Tue, 27 Nov 2012, Sam Lang wrote:
3. When a client acquires the cap for a file, have the mds provide its current
time as well. As the client
On Nov 27, 2012, at 11:05 AM, Sam Lang sam.l...@inktank.com wrote:
On 11/27/2012 12:01 PM, Sage Weil wrote:
On Tue, 27 Nov 2012, David Zafman wrote:
On Nov 27, 2012, at 9:03 AM, Sage Weil s...@inktank.com wrote:
On Tue, 27 Nov 2012, Sam Lang wrote:
3. When a client acquires the cap
On 11/27/2012 12:01 PM, Sage Weil wrote:
On Tue, 27 Nov 2012, David Zafman wrote:
On Nov 27, 2012, at 9:03 AM, Sage Weil s...@inktank.com wrote:
On Tue, 27 Nov 2012, Sam Lang wrote:
3. When a client acquires the cap for a file, have the mds provide its
current
On 11/27/2012 01:38 PM, David Zafman wrote:
On Nov 27, 2012, at 11:05 AM, Sam Lang sam.l...@inktank.com wrote:
On 11/27/2012 12:01 PM, Sage Weil wrote:
On Tue, 27 Nov 2012, David Zafman wrote:
On Nov 27, 2012, at 9:03 AM, Sage Weil s...@inktank.com wrote:
On Tue, 27 Nov 2012, Sam Lang
On Nov 27, 2012, at 1:14 PM, Sam Lang sam.l...@inktank.com wrote:
On 11/27/2012 01:38 PM, David Zafman wrote:
On Nov 27, 2012, at 11:05 AM, Sam Lang sam.l...@inktank.com wrote:
On 11/27/2012 12:01 PM, Sage Weil wrote:
On Tue, 27 Nov 2012, David Zafman wrote:
On Nov 27, 2012, at 9:03
(Sorry for the dupe message. vger rejected due to HTML).
Thanks, I'll try this patch this morning.
Client B should perform a single stat after a notification from Client
A. But, won't Sage's patch still be required, since Client A needs the
MDS time to pass to Client B?
On Tue, Nov 20, 2012 at
This is a description of the clock synchronization issue we are facing
in Hadoop:
Components of Hadoop use mtime as a versioning mechanism. Here is an
example where Client B tests the expected 'version' of a file created
by Client A:
Client A: create file, write data into file.
Client A:
On 11/20/2012 01:44 PM, Noah Watkins wrote:
This is a description of the clock synchronization issue we are facing
in Hadoop:
Components of Hadoop use mtime as a versioning mechanism. Here is an
example where Client B tests the expected 'version' of a file created
by Client A:
Client A:
14 matches
Mail list logo
