[
https://issues.apache.org/jira/browse/HDFS-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752895#comment-15752895
]
Andrew Wang commented on HDFS-6984:
-----------------------------------
bq. The current proposal in HDFS-7878 offers open(FileStatus) instead of
open(PathHandle) to avoid adding new functions to FileSystem for listing,
deleting, renaming, etc. against a PathHandle...
So for the Hive usecase, they would have to pass around a full serialized
FileStatus even though open() only needs the PathHandle field? This API seems
fine for same-process usage (HDFS-9806?) but inefficient for cross-process. I
think UNIX users are also used to the idea of an inode id separate from a file
status.
I still lean toward removing Writable altogether, since it reduces our API
surface. Similarly, I'd rather not open up {{HdfsFileStatus}} as a public API
(without a concrete usecase) since it expands our API surface. The
cross-serialization is also fragile since we need to be careful not to reuse
field numbers across two structures, and I've seen numbering mistakes made
before even for normal PB changes.
> In Hadoop 3, make FileStatus serialize itself via protobuf
> ----------------------------------------------------------
>
> Key: HDFS-6984
> URL: https://issues.apache.org/jira/browse/HDFS-6984
> Project: Hadoop HDFS
> Issue Type: Improvement
> Affects Versions: 3.0.0-alpha1
> Reporter: Colin P. McCabe
> Assignee: Colin P. McCabe
> Labels: BB2015-05-TBR
> Attachments: HDFS-6984.001.patch, HDFS-6984.002.patch,
> HDFS-6984.003.patch, HDFS-6984.nowritable.patch
>
>
> FileStatus was a Writable in Hadoop 2 and earlier. Originally, we used this
> to serialize it and send it over the wire. But in Hadoop 2 and later, we
> have the protobuf {{HdfsFileStatusProto}} which serves to serialize this
> information. The protobuf form is preferable, since it allows us to add new
> fields in a backwards-compatible way. Another issue is that already a lot of
> subclasses of FileStatus don't override the Writable methods of the
> superclass, breaking the interface contract that read(status.write) should be
> equal to the original status.
> In Hadoop 3, we should just make FileStatus serialize itself via protobuf so
> that we don't have to deal with these issues. It's probably too late to do
> this in Hadoop 2, since user code may be relying on the existing FileStatus
> serialization there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
