[
https://issues.apache.org/jira/browse/HDFS-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16553637#comment-16553637
]
Wei-Chiu Chuang commented on HDFS-3584:
---------------------------------------
bq. I think we need to block the older clients to close the file at this stage?
My take is that once recoverLease() or whatever calls that starts lease
recovery reaches NameNode, NN should reject follow-up close()/recoverLease()
calls until it is able to recover the lease. If the lease recovery doesn't
complete, you just can't safely assume the file can be closed (e.g. file
doesn't have sufficient number of replicas)
bq. what if append call takes the new lease ownership and removes the older
client lease?
Meaning append takes over lease without a lease recovery, so it doesn't bump up
GS? That doesn't sounds right to me.
> Blocks are getting marked as corrupt with append operation under high load.
> ---------------------------------------------------------------------------
>
> Key: HDFS-3584
> URL: https://issues.apache.org/jira/browse/HDFS-3584
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 2.0.0-alpha
> Reporter: Brahma Reddy Battula
> Priority: Major
>
> Scenario:
> =========
> 1. There are 2 clients cli1 and cli2 cli1 write a file F1 and not closed
> 2. The cli2 will call append on unclosed file and triggers a leaserecovery
> 3. Cli1 is closed
> 4. Lease recovery is completed and with updated GS in DN and got BlockReport
> since there is a mismatch in GS the block got corrupted
> 5. Now we got a CommitBlockSync this will also fail since the File is already
> closed by cli1 and state in NN is Finalized
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
