I tend to agree with Doug. Having meaningless unused fields in a struct
increases the danger of bugs and imposes the burden of making it clear
that they don't work.
On the subject of modification vs creation time. Modification time is
difficult to support with this kind of architecture. Every write to the
FS would need an update to be made in the namenode which could quickly
become prohibitive. Also, creation time can easily be used to emulate
modification time at the application level when needed, an application
can drop a completion stamp file when it finishes writing a data file
(or any other activity).
Doug Cutting wrote:
Yoram Arnon wrote:
Modifying a structure in an API requires recompilation of the apps
that use
it, so growing it is also undesirable.
Recompiling should not be difficult. If that is truly a concern, then
we should not use a struct, but instead a void* and a set of functions
to access it, or perhaps somehow version-stamp the API, so that the
server/library can operate back-compatibly.
Having a couple extra values that are
set to some default value before they're fully supported is common
enough,
and imposes minimal overhead.
Regardless of what we have there today, chances are we will someday need
to be able to add things to the stat. We don't want to forever be
saddled with unused fields. If nothing else, we'll end up wasting time
explaining to folks that they don't work.
I'd add anything that's remotele relevant from 'stat' to dfsFileInfo.
-1 We are not building a unix FS. For example, the file mode, uid, and
gid are remotely relevant, but, until we design a permission scheme,
these should not appear in dfsFileInfo. We are unlikely to ever support
access-time, but it is remotely relevant, and we may someday.
Doug
