Description of problem: The DistributedFileSystem class reads the blocksize from the properties file defaultBlockSize = conf.getLong("dfs.block.size", DEFAULT_BLOCK_SIZE); We should investigate what the impact is of hardcoding this value and whether we should implement the same behavior as the DistributedFileSystem class.
Since we don't actually have blocks, I think that this is not a bug.
*** Bug 927391 has been marked as a duplicate of this bug. ***
Steve's Comments in 927391: "GlusterFileSystem.getFileStatus() first determines if the object is a file or a directory. If it is a file it returns a new FileStatus objection and passes in 0 for the third parameter, which is the block replication factor. This should be passing in the replica factor set on the volume as indicated by the same methods implementation in the DistributedFileSystem class. To date, we have seen no actual errors with the 0 replica setting, but we need to understand where this gets called by the computational layers, how it gets used and the impact of leaving this hardcoded." So - clearly we need an understanding of how blcoks/replicas work in addition to a rationale for the block size = 0 .
*** Bug 927411 has been marked as a duplicate of this bug. ***
Marking this as low priority since it is research-oriented and doesnt' constitute a bug
Dynamically determining the block size doesn't seem practical or overly beneficial. Per bug triage discussion, moving to close this bug. We can reopen if we later find this is an issue with reproduce case.