From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2130.oracle.com ([156.151.31.86]:57878 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728677AbeIREgV (ORCPT ); Tue, 18 Sep 2018 00:36:21 -0400 Date: Mon, 17 Sep 2018 16:06:49 -0700 From: "Darrick J. Wong" To: Zach Brown Cc: linux-fsdevel Subject: Re: ANNOUNCE: ScoutFS archival filesystem code published Message-ID: <20180917230649.GB4591@magnolia> References: <20180917192303.GA26394@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180917192303.GA26394@lenny> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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