Re: [PATCH] xfstests: add execution of a custom command to fsstress (-x and -X options)

[Jan Schmidt <list.xfs@jan-o-sch.net>]

On Fri, April 05, 2013 at 14:07 (+0200), Jan Schmidt wrote:
> 
> On Mon, March 25, 2013 at 00:51 (+0100), Dave Chinner wrote:
>> On Fri, Mar 22, 2013 at 08:06:49AM +0100, Jan Schmidt wrote:
>>> On Thu, March 21, 2013 at 22:12 (+0100), Dave Chinner wrote:> On Thu, Mar 21,
>>> 2013 at 09:51:05PM +0100, Jan Schmidt wrote:
>>>>>
>>>>>
>>>>> On 21.03.2013 20:50, Dave Chinner wrote:
>>>>>> On Thu, Mar 21, 2013 at 11:59:45AM +0100, Jan Schmidt wrote:
>>>>>>> From: Jan Schmidt <list.btrfs@jan-o-sch.net>
>>>>>>>
>>>>>>> This patch adds execution of a custom command in the middle of all fsstress
>>>>>>> operations. Its intended use is the creation of snapshots in the middle of a
>>>>>>> test run.
>>>>>>
>>>>>> Why do you need fsstress to do this? Why can't you just run fsstress
>>>>>> in the background and run a loop creating periodic snapshots in the
>>>>>> control script?
>>>>>
>>>>> Because I want reproducible results. Same random seed should result in
>>>>> the very same snapshots being created.
>>>>
>>>> Why can't you run fsstress for N operations, run a snapshot,
>>>> then run it again for M operations? That will give you exactly the
>>>> same results, wouldn't it?
>>>
>>> As far as I have understood what fsstress does, the second run would generate
>>> different filenames, i.e. it would never rename / truncate / punch holes into /
>>> ... files  created by the first run - it cannot even know that they exist.
>>
>> Yes, you are right.
>>
>>>>>> Also, did you intend that every process creates a snapshot? i.e. it
>>>>>> looks lik eif you run a 1000 processes, they'll all run a snapshot
>>>>>> operation at X operations? i.e. this will generate nproc * X
>>>>>> snapshots in a single run. This doesn't seem very wise to me....
>>>>>
>>>>> Agreed, I haven't thought of running more than one process. For the sake
>>>>> of reproducibility, I wouldn't want multiple processes for my test case
>>>>> either.
>>>>>
>>>>> I'm not sure if there are other applications than snapshot creation for
>>>>> such a feature, so I cannot argue whether to have each process execute
>>>>> such a command or not.
>>>>
>>>> If such a feature is necessary, I'd suggest that implementing the
>>>> snapshot ioctl as just another operation directly into fsstress is
>>>> probably a better way to implement this functionality. That way you
>>>> can control the frequency via the command line in exactly the same
>>>> way as every other operation....
>>>
>>> What I currently need is a function to make one reasonably weird snapshot. So my
>>> plan goes like this: do n weird operations, make a snapshot (this is going to be
>>> the base snapshot), do n weird operations (partly to the same files), make a
>>> second snapshot (this is going to be the incremental snapshot, I create that one
>>> myself after fsstress is done, currently). Having both snapshots with an equal
>>> number of modification operations isn't required, however at least a fair number
>>> of operations for each of them is desired.
>>
>> Ah, so you're wanting to test incremental backups based on
>> snapshots. Ok, that context puts it in a different light....
>>
>>> Adding it as a normal fsstress operation would generate a whole lot of
>>> snapshots. I could, for like 50k operations, scale all the factors for each
>>> operation accordingly to get a single snapshot out of it. I still won't force it
>>> anywhere near the middle that way, though. Also, going from 50k operation to 60k
>>> operations gets cumbersome that way.
>>
>> *nod*
>>
>>> Plumbing that into fsstress the way I did is the only solution I could think of
>>> to reach the mentioned goals. If nobody else needs it, I can of course keep it
>>> local, here. However, I'd really like to make an xfstest out of it sooner or
>>> later - currently, we've no test at all for (btrfs) send and receive.
>>
>> For send/receive, you should probably start with some basic tests
>> that are easy to verify first. e.g. the equivalent of the basic
>> incremental xfsdump/restore tests like 064/065 which do well
>> defined, easy to verify operations to determine correct behaviour.
> 
> That sounds like a good start.
> 
>> I can see the value in adding a random variant in addition to these
>> basic tests, so I can see how having a predictable callout from
>> fsstress would be useful for incremental xfsdump/restore testing as
>> well.
>>
>> FWIW, what does you current callout execute? A shell script that
>> runs a bunch of other commands that ends with a btrfs send?
> 
> It's basically just "btrfs subvol snapshot", but yeah, for more complex things
> I'd put a shell script there.
> 
>> The biggest question I have about this is how to make it valuable
>> for more types of fsstress execution, especially concurrent
>> execution. I can't see a use (yet) for a per-process callout, but
>> I'm wondering if we should have some kind of "wait for all processes
>> to do N ops, then run the callout" style of synchronisation.
>>
>> I'm not sure what is best here as I don't know the full context of
>> what you are wanting to test (and how), but I think we can come up
>> with something better than "only works for single process
>> invocations". :)
> 
> Well, in fact you do have the full context of what I'm wanting to test, as far
> as I can see it.
> 
> I bet we could came up with a suggestion how to interpret something like the
> proposed -x switch in multi process context. However, I don't like to code for
> hypothetic situations I cannot really imagine a use case for. So, the best thing
> I came up with is a switch that can do something meaningful in single process
> applications of fsstress.
> 
> I'm happy to code the rest of it, if a good suggestion comes up how this could
> be handled and how it could be useful to others as well.

Looks like there are no suggestions how to make -x useful for multiple workers.
Can we then have the single worker solution (original patch) merged for now?

-Jan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs