From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ted Ts'o Subject: Re: Ext4 and xfs problems in dm-thin on allocation and discard Date: Tue, 19 Jun 2012 10:19:33 -0400 Message-ID: <20120619141933.GC10637@thunk.org> References: <4FDF9EBE.2030809@shiftmail.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org To: =?utf-8?B?THVrw6HFoQ==?= Czerner Cc: Spelic , xfs@oss.sgi.com, linux-ext4@vger.kernel.org, device-mapper development List-Id: dm-devel.ids On Tue, Jun 19, 2012 at 04:09:48PM +0200, Luk=C3=A1=C5=A1 Czerner wrote= : >=20 > With thin provisioning you'll get totally different file system > layout than on fully provisioned disk as you push more and more > writes to your drive. This unfortunately has great impact on > performance since file systems usually have a lot of optimization on > where to put data/metadata on the drive and how to read them. > However in case of thinly provisioned storage those optimization > would not help. And yes, you just have to expect lower performance > with dm-thin from the file system on top of it. It is not and it > will never be ideal solution for workloads where you expect the best > performance. One of the things which would be nice to be able to easily set up is a configuration where we get the benefits of thin provisioning with respect to snapshost, but where the underlying block device used by the file system is contiguous. That is, it would be really useful to *not* use thin provisioning for the underlying file system, but to use thin provisioned snapshots. That way we only pay the thinp performance penalty for the snapshots, and not for normal file system operations. This is something that would be very useful both for ext4 and xfs. I talked to Alasdair about this a few months ago at the Collab Summit, and I think it's doable today, but it was somewhat complicaed to set up. I don't recall the details now, but perhaps someone who's more familiar device mapper could outline the details, and perhaps we can either simplify it or abstract it away in a convenient front-end script? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" i= n 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 cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id q5JEJcpn102707 for ; Tue, 19 Jun 2012 09:19:39 -0500 Received: from imap.thunk.org (li9-11.members.linode.com [67.18.176.11]) by cuda.sgi.com with ESMTP id h6C1E5pDscRJRllW (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jun 2012 07:19:37 -0700 (PDT) Date: Tue, 19 Jun 2012 10:19:33 -0400 From: "Ted Ts'o" Subject: Re: Ext4 and xfs problems in dm-thin on allocation and discard Message-ID: <20120619141933.GC10637@thunk.org> References: <4FDF9EBE.2030809@shiftmail.org> 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 Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: =?utf-8?B?THVrw6HFoQ==?= Czerner Cc: linux-ext4@vger.kernel.org, device-mapper development , xfs@oss.sgi.com, Spelic T24gVHVlLCBKdW4gMTksIDIwMTIgYXQgMDQ6MDk6NDhQTSArMDIwMCwgTHVrw6HFoSBDemVybmVy IHdyb3RlOgo+IAo+IFdpdGggdGhpbiBwcm92aXNpb25pbmcgeW91J2xsIGdldCB0b3RhbGx5IGRp ZmZlcmVudCBmaWxlIHN5c3RlbQo+IGxheW91dCB0aGFuIG9uIGZ1bGx5IHByb3Zpc2lvbmVkIGRp c2sgYXMgeW91IHB1c2ggbW9yZSBhbmQgbW9yZQo+IHdyaXRlcyB0byB5b3VyIGRyaXZlLiBUaGlz IHVuZm9ydHVuYXRlbHkgaGFzIGdyZWF0IGltcGFjdCBvbgo+IHBlcmZvcm1hbmNlIHNpbmNlIGZp bGUgc3lzdGVtcyB1c3VhbGx5IGhhdmUgYSBsb3Qgb2Ygb3B0aW1pemF0aW9uIG9uCj4gd2hlcmUg dG8gcHV0IGRhdGEvbWV0YWRhdGEgb24gdGhlIGRyaXZlIGFuZCBob3cgdG8gcmVhZCB0aGVtLgo+ IEhvd2V2ZXIgaW4gY2FzZSBvZiB0aGlubHkgcHJvdmlzaW9uZWQgc3RvcmFnZSB0aG9zZSBvcHRp bWl6YXRpb24KPiB3b3VsZCBub3QgaGVscC4gQW5kIHllcywgeW91IGp1c3QgaGF2ZSB0byBleHBl Y3QgbG93ZXIgcGVyZm9ybWFuY2UKPiB3aXRoIGRtLXRoaW4gZnJvbSB0aGUgZmlsZSBzeXN0ZW0g b24gdG9wIG9mIGl0LiBJdCBpcyBub3QgYW5kIGl0Cj4gd2lsbCBuZXZlciBiZSBpZGVhbCBzb2x1 dGlvbiBmb3Igd29ya2xvYWRzIHdoZXJlIHlvdSBleHBlY3QgdGhlIGJlc3QKPiBwZXJmb3JtYW5j ZS4KCk9uZSBvZiB0aGUgdGhpbmdzIHdoaWNoIHdvdWxkIGJlIG5pY2UgdG8gYmUgYWJsZSB0byBl YXNpbHkgc2V0IHVwIGlzIGEKY29uZmlndXJhdGlvbiB3aGVyZSB3ZSBnZXQgdGhlIGJlbmVmaXRz IG9mIHRoaW4gcHJvdmlzaW9uaW5nIHdpdGgKcmVzcGVjdCB0byBzbmFwc2hvc3QsIGJ1dCB3aGVy ZSB0aGUgdW5kZXJseWluZyBibG9jayBkZXZpY2UgdXNlZCBieQp0aGUgZmlsZSBzeXN0ZW0gaXMg Y29udGlndW91cy4gIFRoYXQgaXMsIGl0IHdvdWxkIGJlIHJlYWxseSB1c2VmdWwgdG8KKm5vdCog dXNlIHRoaW4gcHJvdmlzaW9uaW5nIGZvciB0aGUgdW5kZXJseWluZyBmaWxlIHN5c3RlbSwgYnV0 IHRvIHVzZQp0aGluIHByb3Zpc2lvbmVkIHNuYXBzaG90cy4gIFRoYXQgd2F5IHdlIG9ubHkgcGF5 IHRoZSB0aGlucApwZXJmb3JtYW5jZSBwZW5hbHR5IGZvciB0aGUgc25hcHNob3RzLCBhbmQgbm90 IGZvciBub3JtYWwgZmlsZSBzeXN0ZW0Kb3BlcmF0aW9ucy4gIFRoaXMgaXMgc29tZXRoaW5nIHRo YXQgd291bGQgYmUgdmVyeSB1c2VmdWwgYm90aCBmb3IgZXh0NAphbmQgeGZzLgoKSSB0YWxrZWQg dG8gQWxhc2RhaXIgYWJvdXQgdGhpcyBhIGZldyBtb250aHMgYWdvIGF0IHRoZSBDb2xsYWIgU3Vt bWl0LAphbmQgSSB0aGluayBpdCdzIGRvYWJsZSB0b2RheSwgYnV0IGl0IHdhcyBzb21ld2hhdCBj b21wbGljYWVkIHRvIHNldAp1cC4gIEkgZG9uJ3QgcmVjYWxsIHRoZSBkZXRhaWxzIG5vdywgYnV0 IHBlcmhhcHMgc29tZW9uZSB3aG8ncyBtb3JlCmZhbWlsaWFyIGRldmljZSBtYXBwZXIgY291bGQg b3V0bGluZSB0aGUgZGV0YWlscywgYW5kIHBlcmhhcHMgd2UgY2FuCmVpdGhlciBzaW1wbGlmeSBp dCBvciBhYnN0cmFjdCBpdCBhd2F5IGluIGEgY29udmVuaWVudCBmcm9udC1lbmQKc2NyaXB0PwoK CQkJCQkJLSBUZWQKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCnhmcyBtYWlsaW5nIGxpc3QKeGZzQG9zcy5zZ2kuY29tCmh0dHA6Ly9vc3Muc2dpLmNvbS9t YWlsbWFuL2xpc3RpbmZvL3hmcwo=