On 10/08/2016 12:16 AM, David Sterba wrote:
On Fri, Oct 07, 2016 at 05:26:27PM +0800, Qu Wenruo wrote:
Preferably not. We've managed to avoid pre-built images in xfstests
for 15 years, so there'd have to be a really good reason to start
doing this, especially as once we open that floodgate we'll end up
with everyone wanting to do this and it will blow out the size of
the repository in now time.
Makes sense.
For btrfs-progs, which includes test images, it already takes about 77M,
even we have tried our best to reduce image size.
The number 77M is bogus. Clean checkout of the kernel.org repository is
15M in total, the .git directory is 5M and all the images are 7.3MB in
total. We're not close to any scary numbers yet. Should we need large
images, I'll create a separate repository for that.
If the issue is just timing or being unable to trigger an error
at the right time, this is what error injection frameworks or
debug-only sysfs hooks are for. The XFS kernel code has both,
xfstests use both, and they pretty much do away with the need for
custom binary filesystem images for such testing...
So again, btrfs is lacking infrastructure for debug.
Depends what exactly you need. IIRC Filipe once submitted a patch for
transaction failure injection but then realzied that he could achieve
the same using the flaky device. You can try to take a snapshot of the
block device after using the freeze syscall. More specific tasks would
need code support. You definetelly know about the btrfs-corrupt-block
utility so you can use it to creatively damage the filesystem structures.
Btrfs-corrupt-block is also my first guess.
But the problem turns out that, I must implement (at least part of)
relocation code in btrfs-progs, to create the desired image, for my
specific usage.
That will be a lot of work, at least not something I could do in one or
two months.
But thanks for all your advice, I'm aware of the necessity of these
infrastructure now.
Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
