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. Signed-off-by: Jan Schmidt <list.btr
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? Also, did you intend that every process create
Because I want reproducible results. Same random seed should result in the very same snapshots being created. Agreed, I haven't thought of running more than one process. For the sake of reproducibili
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? If such a feature is necessary, I'd suggest
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 c
Yes, you are right. Ah, so you're wanting to test incremental backups based on snapshots. Ok, that context puts it in a different light.... *nod* For send/receive, you should probably start with some
That sounds like a good start. It's basically just "btrfs subvol snapshot", but yeah, for more complex things I'd put a shell script there. Well, in fact you do have the full context of what I'm want
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
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 I don't see why not. Looks good. Rev