Currently the only way to log fsstress's output is to redirect it's shared
stdout to pipe which is very painfull because:
1) Pipe writers are serialized via i_mutex so we waste cpu-cores power on stupid
sinchronization for loging purpose, instead of hunting real race conditions,
and bugs inside file system.
2) Usually output is corrupted due to luck of sychronization on shared stdout.
Since fsstress's children operate on independend paths, let's just open didicated
log file for each child and simply avoid useless sycnhronization.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Fsstress exec behaviour is not completely determinated in case of
low resources mode due to ENOMEM, ENOSPC, etc. In some places we
call stat(2). This information may be halpfull for future
investigations purposes. Let's dump stat info where possible.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Use correct types for bulkstat structure to avoid pointer warnings.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Merge of master-melb:xfs-cmds:24197a by kenmcd.
When tracking down an error msg from fsstress, I had no idea what
was going on. So I have added a bunch of comments to the code
and added some more diagnostics (in verbose mode). Have also passed
back some failures which weren't directly before.
Hopefully this will not change the ops which are called for
a given rand-seed run.
Dmitry Monakhov
Dave Chinner
Eric Sandeen
Nathan Scott
Tim Shimmin
ptools
fsgqa