[
https://issues.apache.org/jira/browse/HDFS-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110133#comment-14110133
]
Colin Patrick McCabe commented on HDFS-6898:
--------------------------------------------
{code}
/**
@@ -62,8 +62,8 @@ public ReplicaBeingWritten(Block block,
* @param writer a thread that is writing to this replica
*/
public ReplicaBeingWritten(long blockId, long len, long genStamp,
- FsVolumeSpi vol, File dir, Thread writer ) {
- super( blockId, len, genStamp, vol, dir, writer);
+ FsVolumeSpi vol, File dir, Thread writer, long maxBlockLengthHint) {
+ super(blockId, len, genStamp, vol, dir, writer, maxBlockLengthHint);
{code}
Need JavaDoc for the new parameter, here and in a few other places.
{code}
+ long spacePreviouslyReserved = 0;
+ if (replicaInfo instanceof ReplicaBeingWritten) {
+ spacePreviouslyReserved =
+ ((ReplicaBeingWritten) replicaInfo).getBytesReserved();
+ }
+ File dest = v.addFinalizedBlock(bpid, replicaInfo, f,
spacePreviouslyReserved);
{code}
instanceof seems ugly here. How about a method in the base class that returns
0, which gets overridden by ReplicaBeingWritten?
It seems like some places we talk about "reserved space" and others we use
"block length hints". Maybe it makes more sense to use all one terminology or
the other, and have a comment in the code that the reserved space comes from
block length hints?
The unit test is good, but we should make absolutely sure that rbw space can't
"leak". Can we add a stress test that creates and removes a bunch of files and
checks that we end up back at 0 reserved space?
> DN must reserve space for a full block when an RBW block is created
> -------------------------------------------------------------------
>
> Key: HDFS-6898
> URL: https://issues.apache.org/jira/browse/HDFS-6898
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: datanode
> Affects Versions: 2.5.0
> Reporter: Gopal V
> Assignee: Arpit Agarwal
> Attachments: HDFS-6898.01.patch, HDFS-6898.03.patch
>
>
> DN will successfully create two RBW blocks on the same volume even if the
> free space is sufficient for just one full block.
> One or both block writers may subsequently get a DiskOutOfSpace exception.
> This can be avoided by allocating space up front.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
