From: Eric Sandeen <sandeen@sandeen.net>
To: Zach Brown <zab@zabbo.net>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH 1/2] fstests: use mount/umount helpers everywhere
Date: Fri, 20 Mar 2015 15:01:33 -0500 [thread overview]
Message-ID: <550C7C9D.4070108@sandeen.net> (raw)
In-Reply-To: <550C6DFB.6040506@sandeen.net>
On 3/20/15 1:59 PM, Eric Sandeen wrote:
> On 3/20/15 1:56 PM, Zach Brown wrote:
>> On Fri, Mar 20, 2015 at 11:13:47AM -0500, Eric Sandeen wrote:
>>> Replace every explicit mount/umount of scratch or test devices
>>> with helper functions. This allows the next patch to add in hooks
>>> to these functions in order to set up & tear down overlayfs on
>>> every mount/umount.
>>
>> Yeah, I don't know about this.
>>
>> For nfs testing we don't setup xfstests to test xfs on block devices and
>> then then magically configure nfs to export and mount it on the side.
>>
>> Wouldn't we treat overlayfs the same way? It'd be its own fstype whose
>> underlying resources are fs paths?
>
> Yeah, maybe I need to rethink it. TBH, I'm not really clear on how
> nfs gets set up in fstests, but I guess I should look.
Hrmph, well (talking to the duck, here) - nfs & cifs have no mkfs, no
fs check, etc. Overlayfs tests really should, I think. So it's not
quite like the net-fs tests.
Maybe what we need is an "FSTYP=overlayfs" but but another type for
the underlying filesystem. And then that starts to look, I think,
a lot like what I sent...
-Eric
next prev parent reply other threads:[~2015-03-20 20:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 16:11 [PATCH 0/2] fstests: rudimentary overlayfs testing Eric Sandeen
2015-03-20 16:13 ` [PATCH 1/2] fstests: use mount/umount helpers everywhere Eric Sandeen
2015-03-20 18:56 ` Zach Brown
2015-03-20 18:59 ` Eric Sandeen
2015-03-20 20:01 ` Eric Sandeen [this message]
2015-03-20 21:01 ` Zach Brown
2015-03-20 16:22 ` [PATCH 2/2] fstests: Add overlayfs support Eric Sandeen
2015-03-20 18:57 ` Eric Sandeen
2015-04-02 14:41 ` Jan Tulak
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=550C7C9D.4070108@sandeen.net \
--to=sandeen@sandeen.net \
--cc=fstests@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.