Devaraj Das wrote:
I was thinking that we really don't require the mCreationTime field in the dfsFileInfo struct and instead have mModificationTime. For now, mModificationTime is really the time at which the file got created.
We can always grow the API later, but it's hard to ever shrink it. So I'd go with the minimum for now and only include a single time. I'd suspect application code more often requires a modification time, so let's call it mModificationTime for now. Does that make sense?
We can have mBlockSize too in the dfsFileInfo struct. This is the value returned by the getBlockSize API considering the current impl of DFS. But I observed from the mail exchanges that blocksize could be variable in the future.
The current implementation internally supports variable block sizes within a file, but, for performance, we'll probably move towards a fixed block size for an entire file system. Again, I think we should aim for the minimal API. So I'd be happy with just a global per-FS blocksize in the API. We can always later add per-file blocksizes if we need these, and then interpret the FS blocksize as a default. Application uses of blocksize will be to optimize computations, so if, e.g., a legacy application someday uses the global FS blocksize when per-file blocksizes are supported, then it will still run, just perhaps more slowly when operating on files of non-default block size.
Doug
