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