From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Bernd Schubert'" <bernd.schubert@fastmail.fm>,
"'Kent Overstreet'" <kent.overstreet@gmail.com>,
<linux-kernel@vger.kernel.org>, <linux-bcachefs@vger.kernel.org>,
<linux-fsdevel@vger.kernel.org>
Subject: RE: bcachefs - snapshots
Date: Mon, 27 Sep 2021 09:43:19 -0700 [thread overview]
Message-ID: <000901d7b3be$c7783120$56689360$@mindspring.com> (raw)
In-Reply-To: <dbe56ac2-22bd-74d5-ab5d-9f6673884212@fastmail.fm>
> On 9/27/21 3:49 AM, Kent Overstreet wrote:
> > Snapshots have been merged! 9 months of work and 3k lines of new code,
> > finally released. Some highlights:
> >
> > - btrfs style subvolumes & snapshots interface
> > - snapshots are writeable
> > - highly scalable: number of snapshots is limited only by your disk
> > space
> > - highly space efficient: no internal fragmentation issues
> >
> > Design doc here: https://bcachefs.org/Snapshots/
> >
> > The core functionality is complete - snapshot creation and deletion
> > works, fsck changes are done (most of the complexity was in making
> > fsck work without O(number of snapshots) performance - tricky). Everything
> else is a todo item:
> >
> > - still need to export different st_dev for files in different subvolumes
> > (we'll never allocate a new inode with an inode number that collides with an
> > inode inother subvolume - but snapshots will naturally result in colliding
> > inode numbers)
>
> With my limited high level view on it - shouldn't you discuss with Neil about a
> solution and to avoid going the btrfs route for colliding inode numbers?
I was going to ask that also having been watching the btrfs subvolume saga. As maintainer of the Ganesha user space NFS server I have an interest in this also though we haven't had anyone talk about bcachefs yet.
Frank
prev parent reply other threads:[~2021-09-27 16:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-27 1:49 bcachefs - snapshots Kent Overstreet
2021-09-27 13:06 ` Bernd Schubert
2021-09-27 16:43 ` Frank Filz [this message]
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='000901d7b3be$c7783120$56689360$@mindspring.com' \
--to=ffilzlnx@mindspring.com \
--cc=bernd.schubert@fastmail.fm \
--cc=kent.overstreet@gmail.com \
--cc=linux-bcachefs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.