From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josef Bacik Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Working towards better power fail testing Date: Wed, 10 Dec 2014 10:09:54 -0500 Message-ID: <54886242.6050704@fb.com> References: <5486221D.6000006@fb.com> <20141210112759.GC25671@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: , To: Jan Kara Return-path: Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:45379 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756423AbaLJPKC (ORCPT ); Wed, 10 Dec 2014 10:10:02 -0500 In-Reply-To: <20141210112759.GC25671@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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