hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Boudnik (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (HADOOP-5744) Revisit append
Date Tue, 28 Apr 2009 00:01:30 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703448#action_12703448
] 

Konstantin Boudnik edited comment on HADOOP-5744 at 4/27/09 5:00 PM:
---------------------------------------------------------------------

Hairong,

I've a couple of comments about semantic of clause of the document:
  1. DFS provides "best effort durability" to data in an unclosed file:
    - ... If no replicas of a block being written is available, write fails

While it really sounds like a best effort it has some implications from the stand point of
deterministic testing of the feature. In this test case, shall we always expect the negative
result of the test and dismiss occasional positive results as non-significant? Shall we apply
some kind of heuristic to judge the test case's execution results?

  2. DFS provides "strong durability" to data in a closed file:
    - ... However, file close doesn't guarantee that data has hit the disk, If data does not
hit the disk, restarting DataNode may cause the loss of the data.

While I totally understand the somewhat non-deterministic behavior of this feature (e.g. a
hardware failure might happen in the very instant between a file's close invocation and actual
data storage), I still have a concern or two about the testing perspectives of it. As I understand,
synchronous close() call returns when all DNs have reported the successful flash for their
respective blocks of the file. However, and this is where non-determinism kicks in, a particular
DN's OS might be slow in flushing its own IO buffers and writing the data to disk, and where
the actual data loss could happen in case of sudden restart of the DN. However, from the testing
perspective it creates a certain issues like the follows:
  - let's assume that a test client appends a file in DFS
  - at some point it calls close() and waits for its return
  - let's suppose the test client runs in a distributed harness where another piece of the
test can simulate a failure on a DN, where a replica of the file is located. And the timing
of the failure is happen to be right after this very DN reported the success of the flush()
call. E.g. our assumed test harness can guarantee that data hasn't hit the disk. However,
our test client will see a successful return from the call() method and report the test success
respectively. So, I'm not sure how to deal with this situation too.


      was (Author: cos):
    Hairong,

I've a couple of comments about semantic of clause of the document:
  1. DFS provides "best effort durability" to data in an unclosed file:
    - ... If no replicas of a block being written is available, write fails

While it really sounds like a best effort it has some implications from the stand point of
deterministic testing of the feature. In this test case, shall we always expect the negative
result of the test and dismiss occasional positive results as non-significant? Shall we apply
some kind of heuristic to judge the test case's execution results?

  2. DFS provides "strong durability" to data in a closed file:
    - ... However, file close doesn't guarantee that data has hit the disk, If data does not
hit the disk, restarting DataNode may cause the loss of the data.

While I totally understand the somewhat non-deterministic behavior of this feature (e.g. a
hardware failure might happen in the very instant between a file's close invocation and actual
data storage), I still have a concern or two about the testing perspectives of it. As I understand,
synchronous close() call returns when all DNs have reported the successful flash for their
respective blocks of the file. However, and this is where non-determinism kicks in, a particular
DN's OS might be slow in flushing its own IO buffers and writing the data to disk, and where
the actual data loss could happen in case of sudden restart of the DN. However, from the testing
perspective it creates a certain issues like the follows:
  - let's assume that a test client appends a file in DFS
  - at some point it calls close() and waits for its return
  - let's suppose the test client runs in a distributed harness where another piece of the
test can simulate a failure on a DN, where a replica of the file is located. And the timing
of the failure is happen to be right after this very DN reported the success of the flush()
call. E.g. our assumed test harness can guarantee that data hasn't hit the disk. However,
our test client will see a successful return from the call() method and report the test success
respective. So, I'm not sure how to deal with this situation too.

  
> Revisit append
> --------------
>
>                 Key: HADOOP-5744
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5744
>             Project: Hadoop Core
>          Issue Type: Improvement
>          Components: dfs
>    Affects Versions: 0.20.0
>            Reporter: Hairong Kuang
>            Assignee: Hairong Kuang
>             Fix For: 0.21.0
>
>         Attachments: AppendSpec.pdf
>
>
> HADOOP-1700 and related issues have put a lot of efforts to provide the first implementation
of append. However, append is such a complex feature. It turns out that there are issues that
were initially seemed trivial but needs a careful design. This jira revisits append, aiming
for a design and implementation supporting a semantics that are acceptable to its users.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message