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. 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? 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". :) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
