From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero range Date: Thu, 27 Feb 2014 09:17:57 +1100 Message-ID: <20140226221757.GD29907@dastard> References: <1393355728-12056-1-git-send-email-lczerner@redhat.com> <1393355728-12056-6-git-send-email-lczerner@redhat.com> <20140225205349.GD13647@dastard> <20140225215011.GF13647@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com To: =?utf-8?B?THVrw6HFoQ==?= Czerner Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On Wed, Feb 26, 2014 at 03:58:36PM +0100, Luk=C3=A1=C5=A1 Czerner wrote= : > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > Currently xfs/242 fails on xfs for me > >=20 > > Really? Where's the bug report? I haven't seen a failure on xfs/242 > > on any of my test machines for at least a year, even on 1k block > > size filesystems... > >=20 > > $ sudo ./check xfs/242 > > FSTYP -- xfs (debug) > > PLATFORM -- Linux/x86_64 test2 3.14.0-rc3-dgc+ > > MKFS_OPTIONS -- -f -bsize=3D4096 /dev/vdb > > MOUNT_OPTIONS -- /dev/vdb /mnt/scratch > >=20 > > xfs/242 1s ... 0s > > Ran: xfs/242 > > Passed all 1 tests > > $ >=20 > Ok so once again. Yesterday was rally too late and I've > misinterpreted the diff. It's not that xfs behaves differently, but > rather ext4 behaves differently because we in fact have a code that > will zero out entire unwritten extent if it's small enough rather > than split it into unwritten and written. Yes, we've come across this before, and there are several solutions. this one is used in tests/generic/285: # Disable extent zeroing for ext4 as that change where holes ar created if [ "$FSTYP" =3D "ext4" ]; then DEV=3D`basename $TEST_DEV` echo 0 >/sys/fs/ext4/$DEV/extent_max_zeroout_kb fi > > > and it does behave differently than ext4. > >=20 > > In what way? Does FALLOC_FL_ZERO_RANGE on XFS behave identically to > > XFS_IOC_ZERO_RANGE, or is that different too? Or you haven't tested > > it because you wrote this test as an ext4 specific test and so > > haven't run this specific test exercising the FALLOC_FL_ZERO_RANGE > > path in XFS? >=20 > It does behave differently, but not because of zero_range code, but > rather when writing into uninitialized extent which is small enough. > The extent will not be split but rather converted to initialized and > respective parts will be zeroed out. >=20 > Btw that's actually the reason why we use >=20 > _filter_hole_fiemap >=20 > filtes instead of >=20 > _filter_fiemap >=20 > I've used in ext4/242. Sure, but even so I think we might do better just to use the above zeroout tune and be explicit in what we expect to happen w.r.t. data vs holes... >=20 > That said I think that both tests fs specific and fs independent > have it's value so I'll create generic/242 as well by using > _filter_hole_fiemap. Just use the first unused generic test number - trying to keep test numbers the same across different subdirs is just going to cause confusion.... > > hole punching - the only difference between a hole punch and a zero > > range on filesystems that use unwritten extents should be that the > > range being operated on has unwritten extents rather a hole..... > >=20 > > > Btw this kind of optimization is actually something I've been > > > thinking of as well for ext4. Rather than going though the hassle= of > > > changing extents around it might be worth in some situation to ze= ro > > > out. But that's an optimization I have not implemented yet. > >=20 > > Exactly my point - until such optimisations are implemented, all th= e > > filesystems should be behaving the same way using unwritten extents= , > > just like for hole punching. Hence the tests should be checking tha= t > > the behaviour is the same across filesystems, just like we do for > > hole punching. >=20 > Using _filter_hole_fiemap filter in such test we would not make a > difference between unwritten and written extent. However in the case > of zero_range this somewhat make the test much less effective so > it'll be worth having fs specific test as well as generic test I > said above. >=20 > Or we could actually directly inspect the data as we do in xfs/290, o= r > generic/290 respectively. The md5sum does the data inspection for us. The whole point of hole punch and zero range and so one is that they are extent manipulation operations. If we don't check that extents have been manipulated correctly, then we aren't testing that the key behaviour the filesystems are supposed to display for those operations.... Cheers, Dave. --=20 Dave Chinner david@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 5D7497F3F for ; Wed, 26 Feb 2014 16:18:03 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 41903304051 for ; Wed, 26 Feb 2014 14:18:03 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id zoj8Mo1nsNlx3B0a for ; Wed, 26 Feb 2014 14:18:00 -0800 (PST) Date: Thu, 27 Feb 2014 09:17:57 +1100 From: Dave Chinner Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero range Message-ID: <20140226221757.GD29907@dastard> References: <1393355728-12056-1-git-send-email-lczerner@redhat.com> <1393355728-12056-6-git-send-email-lczerner@redhat.com> <20140225205349.GD13647@dastard> <20140225215011.GF13647@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: =?utf-8?B?THVrw6HFoQ==?= Czerner Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, xfs@oss.sgi.com T24gV2VkLCBGZWIgMjYsIDIwMTQgYXQgMDM6NTg6MzZQTSArMDEwMCwgTHVrw6HFoSBDemVybmVy IHdyb3RlOgo+IE9uIFdlZCwgMjYgRmViIDIwMTQsIERhdmUgQ2hpbm5lciB3cm90ZToKPiA+ID4g Q3VycmVudGx5IHhmcy8yNDIgZmFpbHMgb24geGZzIGZvciBtZQo+ID4gCj4gPiBSZWFsbHk/IFdo ZXJlJ3MgdGhlIGJ1ZyByZXBvcnQ/IEkgaGF2ZW4ndCBzZWVuIGEgZmFpbHVyZSBvbiB4ZnMvMjQy Cj4gPiBvbiBhbnkgb2YgbXkgdGVzdCBtYWNoaW5lcyBmb3IgYXQgbGVhc3QgYSB5ZWFyLCBldmVu IG9uIDFrIGJsb2NrCj4gPiBzaXplIGZpbGVzeXN0ZW1zLi4uCj4gPiAKPiA+ICQgc3VkbyAuL2No ZWNrIHhmcy8yNDIKPiA+IEZTVFlQICAgICAgICAgLS0geGZzIChkZWJ1ZykKPiA+IFBMQVRGT1JN ICAgICAgLS0gTGludXgveDg2XzY0IHRlc3QyIDMuMTQuMC1yYzMtZGdjKwo+ID4gTUtGU19PUFRJ T05TICAtLSAtZiAtYnNpemU9NDA5NiAvZGV2L3ZkYgo+ID4gTU9VTlRfT1BUSU9OUyAtLSAvZGV2 L3ZkYiAvbW50L3NjcmF0Y2gKPiA+IAo+ID4geGZzLzI0MiAxcyAuLi4gMHMKPiA+IFJhbjogeGZz LzI0Mgo+ID4gUGFzc2VkIGFsbCAxIHRlc3RzCj4gPiAkCj4gCj4gT2sgc28gb25jZSBhZ2Fpbi4g WWVzdGVyZGF5IHdhcyByYWxseSB0b28gbGF0ZSBhbmQgSSd2ZQo+IG1pc2ludGVycHJldGVkIHRo ZSBkaWZmLiBJdCdzIG5vdCB0aGF0IHhmcyBiZWhhdmVzIGRpZmZlcmVudGx5LCBidXQKPiByYXRo ZXIgZXh0NCBiZWhhdmVzIGRpZmZlcmVudGx5IGJlY2F1c2Ugd2UgaW4gZmFjdCBoYXZlIGEgY29k ZSB0aGF0Cj4gd2lsbCB6ZXJvIG91dCBlbnRpcmUgdW53cml0dGVuIGV4dGVudCBpZiBpdCdzIHNt YWxsIGVub3VnaCByYXRoZXIKPiB0aGFuIHNwbGl0IGl0IGludG8gdW53cml0dGVuIGFuZCB3cml0 dGVuLgoKWWVzLCB3ZSd2ZSBjb21lIGFjcm9zcyB0aGlzIGJlZm9yZSwgYW5kIHRoZXJlIGFyZSBz ZXZlcmFsIHNvbHV0aW9ucy4KdGhpcyBvbmUgaXMgdXNlZCBpbiB0ZXN0cy9nZW5lcmljLzI4NToK CiMgRGlzYWJsZSBleHRlbnQgemVyb2luZyBmb3IgZXh0NCBhcyB0aGF0IGNoYW5nZSB3aGVyZSBo b2xlcyBhciBjcmVhdGVkCmlmIFsgIiRGU1RZUCIgPSAiZXh0NCIgXTsgdGhlbgoJREVWPWBiYXNl bmFtZSAkVEVTVF9ERVZgCgllY2hvIDAgPi9zeXMvZnMvZXh0NC8kREVWL2V4dGVudF9tYXhfemVy b291dF9rYgpmaQoKPiA+ID4gYW5kIGl0IGRvZXMgYmVoYXZlIGRpZmZlcmVudGx5IHRoYW4gZXh0 NC4KPiA+IAo+ID4gSW4gd2hhdCB3YXk/IERvZXMgRkFMTE9DX0ZMX1pFUk9fUkFOR0Ugb24gWEZT IGJlaGF2ZSBpZGVudGljYWxseSB0bwo+ID4gWEZTX0lPQ19aRVJPX1JBTkdFLCBvciBpcyB0aGF0 IGRpZmZlcmVudCB0b28/IE9yIHlvdSBoYXZlbid0IHRlc3RlZAo+ID4gaXQgYmVjYXVzZSB5b3Ug d3JvdGUgdGhpcyB0ZXN0IGFzIGFuIGV4dDQgc3BlY2lmaWMgdGVzdCBhbmQgc28KPiA+IGhhdmVu J3QgcnVuIHRoaXMgc3BlY2lmaWMgdGVzdCBleGVyY2lzaW5nIHRoZSBGQUxMT0NfRkxfWkVST19S QU5HRQo+ID4gcGF0aCBpbiBYRlM/Cj4gCj4gSXQgZG9lcyBiZWhhdmUgZGlmZmVyZW50bHksIGJ1 dCBub3QgYmVjYXVzZSBvZiB6ZXJvX3JhbmdlIGNvZGUsIGJ1dAo+IHJhdGhlciB3aGVuIHdyaXRp bmcgaW50byB1bmluaXRpYWxpemVkIGV4dGVudCB3aGljaCBpcyBzbWFsbCBlbm91Z2guCj4gVGhl IGV4dGVudCB3aWxsIG5vdCBiZSBzcGxpdCBidXQgcmF0aGVyIGNvbnZlcnRlZCB0byBpbml0aWFs aXplZCBhbmQKPiByZXNwZWN0aXZlIHBhcnRzIHdpbGwgYmUgemVyb2VkIG91dC4KPiAKPiBCdHcg dGhhdCdzIGFjdHVhbGx5IHRoZSByZWFzb24gd2h5IHdlIHVzZQo+IAo+IF9maWx0ZXJfaG9sZV9m aWVtYXAKPiAKPiBmaWx0ZXMgaW5zdGVhZCBvZgo+IAo+IF9maWx0ZXJfZmllbWFwCj4gCj4gSSd2 ZSB1c2VkIGluIGV4dDQvMjQyLgoKU3VyZSwgYnV0IGV2ZW4gc28gSSB0aGluayB3ZSBtaWdodCBk byBiZXR0ZXIganVzdCB0byB1c2UgdGhlIGFib3ZlCnplcm9vdXQgdHVuZSBhbmQgYmUgZXhwbGlj aXQgaW4gd2hhdCB3ZSBleHBlY3QgdG8gaGFwcGVuIHcuci50LiBkYXRhCnZzIGhvbGVzLi4uCgo+ IAo+IFRoYXQgc2FpZCBJIHRoaW5rIHRoYXQgYm90aCB0ZXN0cyBmcyBzcGVjaWZpYyBhbmQgZnMg aW5kZXBlbmRlbnQKPiBoYXZlIGl0J3MgdmFsdWUgc28gSSdsbCBjcmVhdGUgZ2VuZXJpYy8yNDIg YXMgd2VsbCBieSB1c2luZwo+IF9maWx0ZXJfaG9sZV9maWVtYXAuCgpKdXN0IHVzZSB0aGUgZmly c3QgdW51c2VkIGdlbmVyaWMgdGVzdCBudW1iZXIgLSB0cnlpbmcgdG8ga2VlcCB0ZXN0Cm51bWJl cnMgdGhlIHNhbWUgYWNyb3NzIGRpZmZlcmVudCBzdWJkaXJzIGlzIGp1c3QgZ29pbmcgdG8gY2F1 c2UKY29uZnVzaW9uLi4uLgoKPiA+IGhvbGUgcHVuY2hpbmcgLSB0aGUgb25seSBkaWZmZXJlbmNl IGJldHdlZW4gYSBob2xlIHB1bmNoIGFuZCBhIHplcm8KPiA+IHJhbmdlIG9uIGZpbGVzeXN0ZW1z IHRoYXQgdXNlIHVud3JpdHRlbiBleHRlbnRzIHNob3VsZCBiZSB0aGF0IHRoZQo+ID4gcmFuZ2Ug YmVpbmcgb3BlcmF0ZWQgb24gaGFzIHVud3JpdHRlbiBleHRlbnRzIHJhdGhlciBhIGhvbGUuLi4u Lgo+ID4gCj4gPiA+IEJ0dyB0aGlzIGtpbmQgb2Ygb3B0aW1pemF0aW9uIGlzIGFjdHVhbGx5IHNv bWV0aGluZyBJJ3ZlIGJlZW4KPiA+ID4gdGhpbmtpbmcgb2YgYXMgd2VsbCBmb3IgZXh0NC4gUmF0 aGVyIHRoYW4gZ29pbmcgdGhvdWdoIHRoZSBoYXNzbGUgb2YKPiA+ID4gY2hhbmdpbmcgZXh0ZW50 cyBhcm91bmQgaXQgbWlnaHQgYmUgd29ydGggaW4gc29tZSBzaXR1YXRpb24gdG8gemVybwo+ID4g PiBvdXQuIEJ1dCB0aGF0J3MgYW4gb3B0aW1pemF0aW9uIEkgaGF2ZSBub3QgaW1wbGVtZW50ZWQg eWV0Lgo+ID4gCj4gPiBFeGFjdGx5IG15IHBvaW50IC0gdW50aWwgc3VjaCBvcHRpbWlzYXRpb25z IGFyZSBpbXBsZW1lbnRlZCwgYWxsIHRoZQo+ID4gZmlsZXN5c3RlbXMgc2hvdWxkIGJlIGJlaGF2 aW5nIHRoZSBzYW1lIHdheSB1c2luZyB1bndyaXR0ZW4gZXh0ZW50cywKPiA+IGp1c3QgbGlrZSBm b3IgaG9sZSBwdW5jaGluZy4gSGVuY2UgdGhlIHRlc3RzIHNob3VsZCBiZSBjaGVja2luZyB0aGF0 Cj4gPiB0aGUgYmVoYXZpb3VyIGlzIHRoZSBzYW1lIGFjcm9zcyBmaWxlc3lzdGVtcywganVzdCBs aWtlIHdlIGRvIGZvcgo+ID4gaG9sZSBwdW5jaGluZy4KPiAKPiBVc2luZyBfZmlsdGVyX2hvbGVf ZmllbWFwIGZpbHRlciBpbiBzdWNoIHRlc3Qgd2Ugd291bGQgbm90IG1ha2UgYQo+IGRpZmZlcmVu Y2UgYmV0d2VlbiB1bndyaXR0ZW4gYW5kIHdyaXR0ZW4gZXh0ZW50LiBIb3dldmVyIGluIHRoZSBj YXNlCj4gb2YgemVyb19yYW5nZSB0aGlzIHNvbWV3aGF0IG1ha2UgdGhlIHRlc3QgbXVjaCBsZXNz IGVmZmVjdGl2ZSBzbwo+IGl0J2xsIGJlIHdvcnRoIGhhdmluZyBmcyBzcGVjaWZpYyB0ZXN0IGFz IHdlbGwgYXMgZ2VuZXJpYyB0ZXN0IEkKPiBzYWlkIGFib3ZlLgo+IAo+IE9yIHdlIGNvdWxkIGFj dHVhbGx5IGRpcmVjdGx5IGluc3BlY3QgdGhlIGRhdGEgYXMgd2UgZG8gaW4geGZzLzI5MCwgb3IK PiBnZW5lcmljLzI5MCByZXNwZWN0aXZlbHkuCgpUaGUgbWQ1c3VtIGRvZXMgdGhlIGRhdGEgaW5z cGVjdGlvbiBmb3IgdXMuIFRoZSB3aG9sZSBwb2ludCBvZgpob2xlIHB1bmNoIGFuZCB6ZXJvIHJh bmdlIGFuZCBzbyBvbmUgaXMgdGhhdCB0aGV5IGFyZSBleHRlbnQKbWFuaXB1bGF0aW9uIG9wZXJh dGlvbnMuIElmIHdlIGRvbid0IGNoZWNrIHRoYXQgZXh0ZW50cyBoYXZlIGJlZW4KbWFuaXB1bGF0 ZWQgY29ycmVjdGx5LCB0aGVuIHdlIGFyZW4ndCB0ZXN0aW5nIHRoYXQgdGhlIGtleSBiZWhhdmlv dXIKdGhlIGZpbGVzeXN0ZW1zIGFyZSBzdXBwb3NlZCB0byBkaXNwbGF5IGZvciB0aG9zZSBvcGVy YXRpb25zLi4uLgoKQ2hlZXJzLAoKRGF2ZS4KLS0gCkRhdmUgQ2hpbm5lcgpkYXZpZEBmcm9tb3Ji aXQuY29tCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwp4 ZnMgbWFpbGluZyBsaXN0Cnhmc0Bvc3Muc2dpLmNvbQpodHRwOi8vb3NzLnNnaS5jb20vbWFpbG1h bi9saXN0aW5mby94ZnMK