[jira] [Comment Edited] (HIVE-20338) LLAP: Force synthetic file-id for filesystems which have HDFS protocol impls with POSIX mutation semantics

["Gopal V (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HIVE-20338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16578809#comment-16578809 ] 

Gopal V edited comment on HIVE-20338 at 8/13/18 7:22 PM:
---------------------------------------------------------

[~sershe]: this is true only for HDFS NameNodes (& appends don't change inode-ids - people who want to drive an HDFS developer insane can truncate an HDFS file to a smaller length and then append to it again to overwrite existing blocks).

FYI - https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1adv_Overviewhdfs.htm



was (Author: gopalv):
[~sershe]: this is true only for HDFS NameNodes.

FYI - https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1adv_Overviewhdfs.htm


> LLAP: Force synthetic file-id for filesystems which have HDFS protocol impls with POSIX mutation semantics
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: HIVE-20338
>                 URL: https://issues.apache.org/jira/browse/HIVE-20338
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Gopal V
>            Priority: Major
>         Attachments: HIVE-20338.WIP.patch
>
>
> HDFS client protocol is not a guarantee of the immutability of files - the synthetic file-id includes the mtime of the file as well, which is a fail-safe for filesystems which implement the client wire protocol without offering the same storage side restrictions on immutability (i.e allow NFS read-write-modify on the backend).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)