On Fri, Aug 5, 2011 at 11:28 AM, Todd Lipcon <t...@cloudera.com> wrote:
> On Fri, Aug 5, 2011 at 10:21 AM, M. C. Srivas <mcsri...@gmail.com> wrote:
> > On Fri, Aug 5, 2011 at 9:42 AM, Jean-Daniel Cryans <jdcry...@apache.org
> >wrote:
> >
> >> On Fri, Aug 5, 2011 at 8:52 AM, M. C. Srivas <mcsri...@gmail.com>
> wrote:
> >> > The normal behavior would be for the HMaster to make the hlog
> read-only
> >> > before processing it.... very simple fencing and works on all Posix or
> >> > close-to-Posix systems. Does that not work on HDFS?
> >>
> >> I'm sure you know the answer to that :)
> >>
> >
> > Actually, I really don't know HDFS details ... so does chmod work for
> all?
> >
> > We're thinking for submitting a patch to Hbase that does the following:
> >
> > recoverLease() {
> > if (fs is DistributedFileSystem) {
> > call the NN's recover lease API
> > } else if (fs supports setPermissions) {
> > call fs.setPermissions
>
> In most filesystems, permissions are only checked when a file is
> opened, not on every write. That's true of HDFS as well as Linux's
> behavior with all local filesystems I'm aware of. As far as I know
> it's the case with most NFS filers as well. Hence the existence of
> explicit fencing commands accessible via remote administrative
> interfaces on NetApps, for example.
>
Well, there's no "open" or "close" in the NFS protocol. A client does
lookup/getattr and may cache the results forever ... and a week later come
back and issue a write.
Looks like NFS does something else altogether. From the RFC
http://www.armware.dk/RFC/rfc/rfc1813.html
"On a local file system, a user can open
a file and then change the permissions so that no one is
allowed to touch it, but will still be able to write to the
file because it is open. On a remote file system, by
contrast, the write would fail. To get around this problem,
the server's permission checking algorithm should allow the
owner of a file to access it regardless of the permission
setting. This is needed in a practical NFS version 3 protocol
server implementation, but it does depart from correct local
file system semantics."
>
> -Todd
> --
> Todd Lipcon
> Software Engineer, Cloudera
>
