[
https://issues.apache.org/jira/browse/HBASE-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409257#comment-13409257
]
stack commented on HBASE-6233:
------------------------------
It'd be a radical change Matteo. It feels like a hbase 2.0 kinda thing rather
than a 0.96-type change (But this is a 'brainstorm' issue so we have license to
talk hypotheticals).
I think we could auto-migrate from the one format to the new; new hfiles would
be written into new location in hdfs while we'd read the old unmigrated hfiles
from the old layout ("Policy" for compatibility up to this is that versions go
forward perhaps w/ a "migration step" but preferably not and we do not have to
support reverting an upgrade... thats "policy" so far).
Would we need x-row transactions updating files in .META.? I don't think so.
Read/write locks might be enough.
We might need to let .META. split now that it can grow largish fast.
We've had "interesting" issues updating .META. in the past: e.g. socket timeout
on client side but the edit went through anyways.... that kinda thing. Now the
repercussions of failed or false positive fail will be larger?
Yeah, instead of looking inside hdfs, hbck will have to read .META. In hdfs,
we'd still have tables and regions, or not?
> [brainstorm] snapshots: hardlink alternatives
> ---------------------------------------------
>
> Key: HBASE-6233
> URL: https://issues.apache.org/jira/browse/HBASE-6233
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Matteo Bertozzi
> Assignee: Matteo Bertozzi
> Attachments: Restore-Snapshot-Hardlink-alternatives.pdf
>
>
> Discussion ticket around snapshots and hardlink alternatives.
> (See the HDFS-3370 discussion about hardlink and implementation problems)
> (taking for a moment WAL out of the discussion and focusing on hfiles)
> With hardlinks available taking snapshot will be fairly easy:
> * (hfiles are immutable)
> * hardlink to .snapshot/name to take snapshot
> * hardlink from .snapshot/name to restore the snapshot
> * No code change needed (on fs.delete() only one reference is deleted)
> but we don't have hardlinks, what are the alternatives?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
