From patchwork Thu Apr 8 04:37:36 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Sandeen X-Patchwork-Id: 49687 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 8779EB7D1C for ; Thu, 8 Apr 2010 14:37:43 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750829Ab0DHEhm (ORCPT ); Thu, 8 Apr 2010 00:37:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16521 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750746Ab0DHEhl (ORCPT ); Thu, 8 Apr 2010 00:37:41 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o384betk017114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Apr 2010 00:37:40 -0400 Received: from liberator.sandeen.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o384baEY021279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 00:37:39 -0400 Message-ID: <4BBD5D90.4090203@redhat.com> Date: Wed, 07 Apr 2010 23:37:36 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nebojsa Trpkovic CC: linux-ext4@vger.kernel.org Subject: Re: "data=writeback" and TRIM don't get along References: <4BBD285B.9000603@gmail.com> <4BBD2FDF.4040407@redhat.com> <4BBD3365.90306@gmail.com> <4BBD5740.4070101@redhat.com> In-Reply-To: <4BBD5740.4070101@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Eric Sandeen wrote: > I'll have to think about the right way to do this... it seems pretty > convoluted to me right now. > Something like this probably works, but I really REALLY would not test it on an important filesystem. :) I'm not sure it's a good idea to discard it before returning it to the prealloc pool, because it may well get re-used again quickly.... not sure if that's helpful. Just a note, I think eventually we may move to more of a batch discard in the background, because these little discards are actually quite inefficient on the hardware we've tested so far. -Eric p.s. really. Don't test this with important data. I haven't tested it at all yet. --- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux-2.6/fs/ext4/mballoc.c =================================================================== --- linux-2.6.orig/fs/ext4/mballoc.c +++ linux-2.6/fs/ext4/mballoc.c @@ -4602,6 +4606,8 @@ do_more: mb_clear_bits(bitmap_bh->b_data, bit, count); ext4_mb_free_metadata(handle, &e4b, new_entry); } else { + ext4_fsblk_t discard_block; + /* need to update group_info->bb_free and bitmap * with group lock held. generate_buddy look at * them with group lock_held @@ -4609,6 +4615,11 @@ do_more: ext4_lock_group(sb, block_group); mb_clear_bits(bitmap_bh->b_data, bit, count); mb_free_blocks(inode, &e4b, bit, count); + discard_block = bit + + ext4_group_first_block_no(sb, block_group); + trace_ext4_discard_blocks(sb, + (unsigned long long)discard_block, count); + sb_issue_discard(sb, discard_block, count); ext4_mb_return_to_preallocation(inode, &e4b, block, count); }