Description of problem: append is implemented in the DistributedFileSystem class. I'm unsure why this is not implemented in GlusterFileSystem at all. Given that we are POSIX compliant I would imagine this behavior is relatively simple to implement.
Per the apache HCFS discussion, append(..) is a MAY implement for filesystems. append(..) is generally avoided all together as it raises concurrency issues that aren't well defined in HCFS/HDFS. The code to implement isn't hard, but i'd suggest avoiding this as long as possible. At the most defined state this would be a very slow right path, and at the least defined state it could cause consistency problems. The behavior or append(..) operations to already opened files, or when the append(..) data becomes consistent isn't well defined for HCFS. Ref: https://issues.apache.org/jira/browse/HADOOP-9371 Steve, I'll re-assign to you for decision close or size & plan if so desired.
I think there is a possibility that FS Append semantics are required by HBase for its Write Ahead Log (WAL) and we match expected FileSystem semantics for the standard clients of the Hadoop FileSystem. Can you verify that the append semantics are not required by HBase?
code re-written as of 2.0. GlusterFileSystem extends FilterFileSystem GlusterVolume extends RawLocalFileSystem. the append behavior is inherited (and supported) in RawLocalFileSystem. this bug can be closed.
This solution is no longer available from Red Hat.