From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: [PATCH v2 0/10] fs: Introduce FALLOC_FL_INSERT_RANGE for fallocate Date: Mon, 2 Jun 2014 11:02:58 -0400 Message-ID: <20140602150258.GG30598@thunk.org> References: <003601cf6aa7$883103b0$98930b10$@samsung.com> <000d01cf7ca3$98335c50$c89a14f0$@samsung.com> <002201cf7e59$2e684c10$8b38e430$@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Namjae Jeon , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, 'Ashish Sangwan' , linux-fsdevel@vger.kernel.org, 'linux-ext4' To: =?utf-8?B?THVrw6HFoQ==?= Czerner Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com List-Id: linux-ext4.vger.kernel.org T24gTW9uLCBKdW4gMDIsIDIwMTQgYXQgMDM6MDY6MTNQTSArMDIwMCwgTHVrw6HFoSBDemVybmVy IHdyb3RlOgo+ID4gPiBTbyB3aGF0IHdpbGwgaGFwcGVuIHdoZW4gdGhlcmUgaXMgbm90IGVub3Vn aCBzcGFjZSB3aGVuICJpbnNlcnRpbmcgYQo+ID4gPiByYW5nZSIgPyBBbmQgaG93IHNob3VsZCB1 c2VyIHByb2NlZWQgZnJvbSB0aGVyZSA/Cj4gPiBJZiBpbnNlcnQgcmFuZ2UgZmFpbHMgd2l0aCBh biBFTk9TUEMgZXJyb3IsIHVzZXIgY291bGQgdXNlIGNvbGxhcHNlCj4gPiByYW5nZSBvbiB0aGUg c2FtZSByYW5nZSB0byByZW1vdmUgdGhlIGhvbGUuCj4gPiBBbmQgYWZ0ZXIgZnJlZWluZyBtb3Jl IHNwYWNlLCBoZSBjYW4gYWdhaW4gdHJ5IGluc2VydGluZyByYW5nZS4KPiA+IE9mY291cnNlLCB0 aGlzIHR5cGUgb2YgZ3VpZGFuY2Ugc2hvdWxkIGJlIHByb3Blcmx5IGRvY3VtZW50ZWQgaW4KPiA+ IG1hbnBhZ2UuIFdoZW4gdXBkYXRpbmcgZmFsbG9jYXRlKDIpIG1hbnBhZ2UsIEkgd2lsbCBrZWVw ICBpbiBtaW5kIHRvCj4gPiBkZXNjcmliZSBFTk9TUEMgaGFuZGxpbmcuCj4gCj4gV2h5IGNvbGxh cHNlID8gVGhlIGhvbGUgaXMgYWxyZWFkeSB0aGVyZSByaWdodCA/IFdoeSBub3QganVzdCB1c2UK PiBmYWxsb2NhdGUgdG8gYWxsb2NhdGUgdGhlIHNwYWNlIGZvciB0aGUgaG9sZS4gQW5kIHRoYXQn cyBteSBwb2ludAo+IGFjdHVhbGx5LiBXaHkgbm90IGRvIGl0IHRoaXMgd2F5IGluIHRoZSBmaXJz dCBwbGFjZSwgYmVjYXVzZSB0aGlzIGlzCj4gcmVhbGx5IGNvdW50ZXJpbnR1aXRpdmUuCgpJdCdz IHdvcnNlIHRoYW4gdGhhdC4gIEl0J3MgcG9zc2libGUgdGhhdCB0aGUgcmVhc29uIHdoeSB5b3Ug Z290IHRoZQpFTk9TUEMgd2FybmluZyB3YXMgYmVjYXVzZSB0aGUgb3BlcmF0aW9uIHRvIG1vdmUg dGhlIGV4dGVudHMgZG93bgpyZXF1aXJlZCBhbGxvY2F0aW5nIGEgYmxvY2ssIGFuZCBpdCB3YXMg KnRoYXQqIGJsb2NrIGFsbG9jYXRpb24gd2hpY2gKZmFpbGVkLiAgU28gaXQncyBub3QgZGV0ZXJt aW5pc3RpYyB3aGV0aGVyIG9yIG5vdCB0aGUgZmlsZSdzIGV4dGVudAptYXBwaW5ncyB3ZXJlIG1v ZGlmaWVkIGFmdGVyIGEgRU5PU1BDIGVycm9yLCBhbmQgc28gaXQncyBub3QgY2xlYXIKd2hldGhl ciBvciBub3QgYSBjb2xsYXBzZV9yYW5nZSBmdW5jdGlvbiB3aWxsIHVuZG8gdGhlIHJhbmdlIHRo YXQgaGFkCmJlZW4gaW5zZXJ0ZWQgLS0tIG9yIHdoZXRoZXIgaXQgZW5kcyB1cCBkZWxldGluZyBl eGlzdGluZyBkYXRhIGJsb2Nrcy4KCkluIGdlbmVyYWxseSwgeW91IHJlYWxseSB3YW50IHN5c3Rl bSBjYWxscyB0byBoYXZlIGFsbC1vci1ub3RoaW5nCmVmZmVjdHMsIHdoZXJlIGlmIHRoZSBzeXN0 ZW0gY2FsbCByZXR1cm5zIGFuIGVycm9yLCB0aGUgc3RhdGUgb2YgdGhlCmZpbGUgaGFzIG5vdCBi ZWVuIGNoYW5nZWQuICBBbmQgZm9yIHRoYXQgcmVhc29uLCBJIGFncmVlIHdpdGggTHVrw6HFoQp0 aGF0IGl0IGlzIHJlYWxseSBhIGdvb2QgaWRlYSB0byBkZWNvdXBsZSBtb3ZpbmcgdGhlIGJsb2Nr cyBkb3duLCBhbmQKYWxsb2NhdGluZyBzcGFjZSAtLS0gYW5kIHRvIG1ha2Ugc3VyZSB0aGF0IGlm IHRoZXJlIGlzIGFueSBmYWlsdXJlCndoaWxlIGluc2VydGluZyB0aGUgcmFuZ2UsIHRoZSBzdGF0 ZSBvZiB0aGUgZmlsZSBpcyBub3QgbW9kaWZpZWQgYXQgYWxsLgoKQ2hlZXJzLAoKCQkJCQktIFRl ZAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KeGZzIG1h aWxpbmcgbGlzdAp4ZnNAb3NzLnNnaS5jb20KaHR0cDovL29zcy5zZ2kuY29tL21haWxtYW4vbGlz dGluZm8veGZzCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755612AbaFBPDN (ORCPT ); Mon, 2 Jun 2014 11:03:13 -0400 Received: from imap.thunk.org ([74.207.234.97]:45652 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755432AbaFBPDJ (ORCPT ); Mon, 2 Jun 2014 11:03:09 -0400 Date: Mon, 2 Jun 2014 11:02:58 -0400 From: "Theodore Ts'o" To: =?utf-8?B?THVrw6HFoQ==?= Czerner Cc: Namjae Jeon , "'Dave Chinner'" , "'linux-ext4'" , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, "'Ashish Sangwan'" Subject: Re: [PATCH v2 0/10] fs: Introduce FALLOC_FL_INSERT_RANGE for fallocate Message-ID: <20140602150258.GG30598@thunk.org> Mail-Followup-To: Theodore Ts'o , =?utf-8?B?THVrw6HFoQ==?= Czerner , Namjae Jeon , 'Dave Chinner' , 'linux-ext4' , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, 'Ashish Sangwan' References: <003601cf6aa7$883103b0$98930b10$@samsung.com> <000d01cf7ca3$98335c50$c89a14f0$@samsung.com> <002201cf7e59$2e684c10$8b38e430$@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 02, 2014 at 03:06:13PM +0200, Lukáš Czerner wrote: > > > So what will happen when there is not enough space when "inserting a > > > range" ? And how should user proceed from there ? > > If insert range fails with an ENOSPC error, user could use collapse > > range on the same range to remove the hole. > > And after freeing more space, he can again try inserting range. > > Ofcourse, this type of guidance should be properly documented in > > manpage. When updating fallocate(2) manpage, I will keep in mind to > > describe ENOSPC handling. > > Why collapse ? The hole is already there right ? Why not just use > fallocate to allocate the space for the hole. And that's my point > actually. Why not do it this way in the first place, because this is > really counterintuitive. It's worse than that. It's possible that the reason why you got the ENOSPC warning was because the operation to move the extents down required allocating a block, and it was *that* block allocation which failed. So it's not deterministic whether or not the file's extent mappings were modified after a ENOSPC error, and so it's not clear whether or not a collapse_range function will undo the range that had been inserted --- or whether it ends up deleting existing data blocks. In generally, you really want system calls to have all-or-nothing effects, where if the system call returns an error, the state of the file has not been changed. And for that reason, I agree with Lukáš that it is really a good idea to decouple moving the blocks down, and allocating space --- and to make sure that if there is any failure while inserting the range, the state of the file is not modified at all. Cheers, - Ted