From: Dave Chinner <david@fromorbit.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Philipp Schrader <philipp@peloton-tech.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
linux-xfs <linux-xfs@vger.kernel.org>,
Austin Schuh <austin@peloton-tech.com>,
Alison Chaiken <alison@peloton-tech.com>,
Theodore Tso <tytso@mit.edu>
Subject: Re: Reproducible XFS filesystem artifacts
Date: Wed, 17 Jan 2018 17:34:54 +1100 [thread overview]
Message-ID: <20180117063454.GK6304@dastard> (raw)
In-Reply-To: <20180117061533.GJ6304@dastard>
On Wed, Jan 17, 2018 at 05:15:33PM +1100, Dave Chinner wrote:
> IOWs, you're chasing a goal (100% reproducable filesystem images)
> that simply cannot be acheived via writing files through a
> kernel-based filesystem....
That said, we do have a mechanism for populating XFS filesystems
from userspace in a manner that we may be able to make deterministic
enough for reproducable image file creation: the mkfs.xfs protofile
infrastructure. That runs from mkfs in userspace, and creates the
directory structure and files specified in the protofile. There's
nothing that runs concurrently with this, it will always run the
creation operations in the same order, and I think we could
extend it to specify a global timestamp for all inodes and solve
that problem too.
The protofile infrastructure uses the kernel allocation code which
we already know is deterministic (i.e. gives the same allocation
results for the same operations if the initial state is the same)
and so we can probably get very close to 100% reproducable
filesystem image through this mechanism.
It's need some work and extensions to provide everything that is
needed in a reliable manner, and a bunch of regression tests
added to fstests to make sure it works and keeps working. If you
want to stick with XFS as the base filesystem for your images, this
may be the best way to proceed....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-01-17 6:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-16 4:49 Reproducible XFS filesystem artifacts Philipp Schrader
2018-01-16 7:55 ` Darrick J. Wong
2018-01-17 0:52 ` Philipp Schrader
2018-01-17 4:05 ` Amir Goldstein
2018-01-17 6:15 ` Dave Chinner
2018-01-17 6:34 ` Dave Chinner [this message]
2018-01-22 19:45 ` Philipp Schrader
2018-01-22 19:45 ` Philipp Schrader
2018-01-22 20:28 ` Austin Schuh
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=20180117063454.GK6304@dastard \
--to=david@fromorbit.com \
--cc=alison@peloton-tech.com \
--cc=amir73il@gmail.com \
--cc=austin@peloton-tech.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=philipp@peloton-tech.com \
--cc=tytso@mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox