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@xxxxxxxxxxxxx> >>>>>> >>>>>> 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. Thanks! -Jan _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
