[
https://issues.apache.org/jira/browse/HDFS-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14366496#comment-14366496
]
Tsz Wo Nicholas Sze commented on HDFS-7943:
-------------------------------------------
- In verifyQuotaForUCBlock,
-* let's add a precondition check to make sure delta >= 0 (for append).
-* It should check if (!fsd.getFSNamesystem().isImageLoaded() ||
fsd.shouldSkipQuotaChecks()); see FSDirConcatOp.verifyQuota and
FSDirRenameOp.verifyQuotaForRename.
- We should also verity quota by storage types; see
FSDirConcatOp.computeQuotaDeltas.
- For truncate, the quota should be updated differently as following:
-* Copy-on-truncate for snapshot: need quota check for creating the new block.
Quota usage count is increased.
-* Non-copy-on-truncate OR Copy-on-truncate for upgrade but not snapshot: Quota
usage count is decreased. No quota check is needed.
Do you want to fix truncate in a different JIRA?
> Append cannot handle the last block with length greater than the preferred
> block size
> -------------------------------------------------------------------------------------
>
> Key: HDFS-7943
> URL: https://issues.apache.org/jira/browse/HDFS-7943
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.7.0
> Reporter: Jing Zhao
> Assignee: Jing Zhao
> Priority: Blocker
> Attachments: HDFS-7943.000.patch
>
>
> In HDFS-3689, we remove the restriction from concat that all the source files
> should have the same preferred block size with the target file. This can
> cause a file to contain blocks with size larger than its preferred block size.
> If such block happens to be the last block of a file, and later we append
> data to the file without the {{CreateFlag.NEW_BLOCK}} flag (i.e., appending
> data to the last block), looks like the current client code will keep writing
> to the last block and never allocate a new block.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
