On 12/10/2014 06:27 AM, Jan Kara wrote:
On Mon 08-12-14 17:11:41, Josef Bacik wrote:
Hello,
We have been doing pretty well at populating xfstests with loads of
tests to catch regressions and validate we're all working properly.
One thing that has been lacking is a good way to verify file system
integrity after a power fail. This is a core part of what file
systems are supposed to provide but it is probably the least tested
aspect. We have dm-flakey tests in xfstests to test fsync
correctness, but these tests do not catch the random horrible things
that can go wrong. We are still finding horrible scary things that
go wrong in Btrfs because it is simply hard to reproduce and test
for.
I have been working on an idea to do this better, some may have seen
my dm-power-fail attempt, and I've got a new incarnation of the idea
thanks to discussions with Zach Brown. Obviously there will be a
lot changing in this area in the time between now and March but it
would be good to have everybody in the room talking about what they
would need to build a good and deterministic test to make sure we're
always giving a consistent file system and to make sure our fsync()
handling is working properly. Thanks,
I agree we are lacking in testing this aspect. Just I don't see too much
material for discussion there, unless we have something more tangible -
when we have some implementation, we can talk about pros and cons of it,
what still needs doing etc.
Right that's what I was getting at. I have a solution and have sent it
around but there doesn't seem to be too many people interested in
commenting on it. I figure one of two things will happen
1) My solution will go in before LSF, in which case YAY my job is done
and this is more of an [ATTEND] than a [TOPIC], or
2) My solution hasn't gone in yet and I'd like to discuss my methodology
and how we can integrate it into xfstests, future features, other areas
we could test etc.
Maybe not a full blown slot but combined with a overall testing slot or
hell just a quick lightening talk. Thanks,
Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
