Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of ndimiduk@gmail.com designates
 209.85.220.169 as permitted sender)
MIME-Version: 1.0
From: Nick Dimiduk <ndimiduk@gmail.com>
Date: Wed, 23 Jul 2014 11:56:58 -0700
Message-ID: 
 <CANZa=GsQb-5ub=wG2egc48YRLV7cZ2Wv7h2RkoT1mKiY35708Q@mail.gmail.com>
Subject: HFileLink backreferences
To: hbase-dev <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=20cf3079bcc0d1326104fee0e8b3

--20cf3079bcc0d1326104fee0e8b3
Content-Type: text/plain; charset=UTF-8

Heya,

I see that we maintain backreferences for hfilelinks. This appears to be
used by HFileLinkCleaner to determine when an HFile has no HFileLinks and
thus whether it can be deleted without orphaning those links.

This is problematic for using the mapreduce over snapshot files feature.
However, restoring a snapshot can create HFileLinks to existing files in
the restore directory. Those links then create back-references to the root
path. Thus we have a situation where the user running the MR job requires
write access to the hbase root path.

Was this already discussed in the original ticket (HBASE-8369)? We mention
the requirement of read permissions (and bypassing security) in the release
note, but I didn't note any comments for write. Requiring write permission
effectively means you can only MR as the hbase user, which is pretty much a
non-starter for any interesting integration of feature.

Thoughts?

Thanks,
Nick

--20cf3079bcc0d1326104fee0e8b3--