[
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.
