All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Zach Brown <zab@zabbo.net>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: ANNOUNCE: ScoutFS archival filesystem code published
Date: Mon, 17 Sep 2018 16:06:49 -0700	[thread overview]
Message-ID: <20180917230649.GB4591@magnolia> (raw)
In-Reply-To: <20180917192303.GA26394@lenny>

On Mon, Sep 17, 2018 at 12:23:03PM -0700, Zach Brown wrote:
> Greetings -fsdevel,
> 
> Today we at Versity are opening the code to ScoutFS, the clustered file
> system that we've been developing as part of our larger software stack
> that supports large scale archives.
> 
> The motivation for the project and the architectural decisions that
> we've made can be found in the white paper that is linked off of
> https://www.scoutfs.org/ .   We've also set up a
> scoutfs-devel@scoutfs.org development mailing list and have an open
> Slack channel, both are linked off of the scoutfs.org site.
> 
> The README.md in the kernel module github repo at
> https://github.com/versity/scoutfs-kmod-dev/ describes the quick steps
> needed to get a system up and running.
> 
> For the expert audience, here's the overview of the project:
> 
>  - Clustered file system using a shared block device.
>  - Shared LSM indexing of metadata to encourage concurrent updates.
>  - Integrated archival interfaces (indexing, "offline" extent tracking).
>  - Batch locking to reduce the cost of enforcing full POSIX.
>  - Initial development targets RHEL/CentOS kernels.
>  - What you'd expect: atomic transactions, metadata checksums, extents.
> 
> This code can be considered a rough beta.  The large architectural
> structures are there for review, and what is implemented has been well
> exercised, but a lot remains to be implemented before we declare the
> format fixed and submit the code upstream.
> 
> We're opening the project early to give the community the opportunity to
> contribute to the design and implementation.
> 
> In the coming weeks I'll personally be focusing on some big ticket
> functional items (deleted inode cleanup in particular),  hardening a few
> recovery cases after crashes, and in general spending all of my will
> power focusing on that responsible nonsense instead of getting lost in
> satisfying performance tuning.
> 
> Ask me anything :),

Is there a fsck tool for this? :D

--D

> - z

  reply	other threads:[~2018-09-18  4:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17 19:23 ANNOUNCE: ScoutFS archival filesystem code published Zach Brown
2018-09-17 23:06 ` Darrick J. Wong [this message]
2018-09-18  5:21   ` Zach Brown
2018-09-18 21:42 ` Matthew Wilcox
2018-09-19 17:50   ` Zach Brown
2018-09-19  6:22 ` Richard Weinberger
2018-09-19 17:52   ` Zach Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180917230649.GB4591@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=zab@zabbo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.