On Mon, Feb 13, 2017 at 07:23:56PM -0500, Theodore Ts'o wrote:
[snip]
> Speaking more generally, I'm not a big fan of the config file approach
> for handling iterations, because of the fact that previous sections
> will have side effects on follow-on sections, and I'm interested in
> adding support for test sharding, where different file system test
> scenarios are run on different GCE VM's, and the ambiguities of how
> variables are carried over from one section to another makes life hard.
I agreed, the section configs are not perfect, sometimes I have
SCRATCH_RTDEV "leaked" to other non-rt test sections. I was considering
fixing this problem, but haven't got enough time to figure out a
reasonable idea yet.
>
> It also makes it hard to have multiple file system developers editing
> a single config file since you have to worry about side effects.
> Having separate files and separate directories for differnt file
> system types means that patch collisions are much less likely to have
> unanticipated side effects, or cause merge conflicts for that matter.
> I recognize that the local config file is not something that is
> intended to be managed centrally, but I acutally *like* the fact that
> I can separate file system test scenarios (and where I want to have a
> common understanding across ext4 file system developers for what the
> "bigalloc_1k" test scenario means), from the details of the local
> hardware configuration.
>
> All of this being said, I doubt I'll be able to convince others about
> changing how the local config system works. I do want to be sure I
> understand what are the supported way of testing overlayfs (e.g., will
> the "deprecated" way continue to work forever, or is it going to
> disappear eventually), and while I'd prefer to not have to play games
I'm considering making the old way unsupported eventually at some point,
after a long enough soak time. But if people still want it, I can live
with it too :)
> with the config file if I want to test using overlayfs, if I *do* get
> forced to do it, it would be useful if there were a bit more explicit
With this update, things get simpler if you're not using multi-section
config file, there's an example in commit log of patch 6/9, README is
also updated, but seems we need that kind of detailed example in README
too.
"
For example, the following config file can be used to run tests on
xfs test/scratch partitions:
TEST_DEV=/dev/sda5
TEST_DIR=/mnt/test
SCRATCH_DEV=/dev/sda6
SCRATCH_MNT=/mnt/scratch
FSTYP=xfs
Using the same config file, but executing './check -overlay'...
"
> description of how things like the mkfs mount options, etc. are side
> effected by previous config sections, and how to set up overlayfs
FWIW, Multi-section configs are optional not mandatory for testing
overlayfs. But I agreed that we need more documentation.
> correctly using such a scheme. (e.g., more documentation than just an
> a few lines demonstration of what might go in the config file without
> any detailed semantic explanation of how it all works.)
>
> - Ted
>
> [1] The ambiguity I was taking about. In one part of the
> README.config-state file, it states:
>
> Note that options are carried between sections so the same options does not
> have to be specified in each and every sections. However caution should be
> exercised not to leave unwanted options set from previous sections.
>
> (What does this mean when stanzas are skipped?)
>
> and later on, it says this:
>
> Multiple file systems
> ---------------------
>
> Having different file systems in different config sections is allowed. When
> FSTYP differs in the following section the FSTYP file system will be created
> automatically before running the test.
>
> Note that if MOUNT_OPTIONS, MKFS_OPTIONS, or FSCK_OPTIONS are not directly
> specified in the section it will be reset to the default for a given file
> system.
>
> This seems to imply that configuration paramters such as MKFS_OPTIONS
> do *not* carry over from one config section to another, and is in
Yes, four paramters are not carried across sections, they're unset at
the beginning of each section. In common/config we have
unset MOUNT_OPTIONS
unset MKFS_OPTIONS
unset FSCK_OPTIONS
unset USE_EXTERNAL
Thanks,
Eryu
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
