hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nyamul Hassan <nya...@gmail.com>
Subject Re: [jira] Created: (HBASE-2387) [stargate] FUSE module for mounting Stargate exported tablespaces
Date Tue, 31 May 2011 15:38:25 GMT
On Mar 29, 2010 10:39 PM, "Andrew Purtell (JIRA)" <jira@apache.org> wrote:
> [stargate] FUSE module for mounting Stargate exported tablespaces
> -----------------------------------------------------------------
>                 Key: HBASE-2387
>                 URL: https://issues.apache.org/jira/browse/HBASE-2387
>             Project: Hadoop HBase
>          Issue Type: New Feature
>            Reporter: Andrew Purtell
>            Assignee: Andrew Purtell
>            Priority: Minor
> FUSE: http://fuse.sourceforge.net/
> Create a FUSE translator that mounts Stargate exported tablespaces into
the Linux filesystem namespace. Support Stargate when it is running in
multiuser mode. Should run in either of two modes:
> 1) Map 1:1 the exported tablespace under the mount point.
> 2) Emulate a filesystem, like s3fs (
>    - Stargate multiget and multiput operations can help performance
>    - Translate paths under the mount point to row keys for good load
spreading, {{/a/b/c/file.ext}} becomes {{file.ext/c/b/a}}
>    - Consider borrowing from Tom White's Hadoop S3 FS (HADOOP-574), and
store file data as blocks.
>        -- After fetching the inode can stream all blocks in a Stargate
multiget. This would support arbitrary file sizes. Otherwise there is a
practical limit somewhere around 20-50 MB with default regionserver heaps.
>        -- So,  {{file.ext/c/b/a}} gets the inode. Blocks would be keyed
using the SHA-1 hash of their contents.
>        -- Because new writes produce new blocks with unique hashes, this
is like a dedup filesystem. Use ICV to maintain use counters on blocks.
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.

This looks like a very interesting project. Has there been any movement on


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message