From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Martin K. Petersen" Subject: Re: [PATCH] libata: Whitelist SSDs that are known to properly return zeroes after TRIM Date: Tue, 06 Jan 2015 19:05:40 -0500 Message-ID: References: <20141204170611.GB2995@htj.dyndns.org> <20141205145148.GI4080@htj.dyndns.org> <1418184578.2121.3.camel@HansenPartnership.com> <20141210142927.GA6294@htj.dyndns.org> <20150105162830.GP15833@htj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain Cc: "Martin K. Petersen" , James Bottomley , linux-ide@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Tejun Heo Return-path: Received: from userp1040.oracle.com ([156.151.31.81]:19559 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751070AbbAGAFq (ORCPT ); Tue, 6 Jan 2015 19:05:46 -0500 In-Reply-To: <20150105162830.GP15833@htj.dyndns.org> (Tejun Heo's message of "Mon, 5 Jan 2015 11:28:30 -0500") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: >>>>> "Tejun" == Tejun Heo writes: >> The other use case is the filesystem one where it is common to zero >> block ranges for bitmaps, etc. In many workloads there's is a >> significant win to trimming over writing out many blocks of zeroes. Tejun> Isn't that kinda niche and specialized tho? I don't think so. There are two reasons for zeroing block ranges: 1) To ensure they contain zeroes on subsequent reads 2) To preallocate them or anchor them down on thin provisioned devices The filesystem folks have specifically asked to be able to make that distinction. Hence the patch that changes blkdev_issue_zeroout(). You really don't want to write out gobs and gobs of zeroes and cause unnecessary flash wear if all you care about is the blocks being in a deterministic state. -- Martin K. Petersen Oracle Linux Engineering