From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH 0/1] Batched discard support Date: Thu, 30 Sep 2010 10:55:35 +1000 Message-ID: <20100930005535.GV5665@dastard> References: <1285750466-3579-1-git-send-email-lczerner@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, tytso@mit.edu, sandeen@redhat.com, adilger@dilger.ca To: Lukas Czerner Return-path: Received: from bld-mail17.adl2.internode.on.net ([150.101.137.102]:50840 "EHLO mail.internode.on.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751194Ab0I3A4E (ORCPT ); Wed, 29 Sep 2010 20:56:04 -0400 Content-Disposition: inline In-Reply-To: <1285750466-3579-1-git-send-email-lczerner@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Sep 29, 2010 at 10:54:25AM +0200, Lukas Czerner wrote: > Hi, > > I am working on something I have called "batched discard support" for Ext3 > and Ext4 filesystems. Traditional discard support for filesystems like Ext4 > has been implemented the way that whenever the file is unlinked the > disk-space that the file was using is trimmed (discarded) by > sb_issue_discard() to let the device know that this portion of disk is no > longer in use by the filesystem and can be safely used for wear-leveling. > > However, this approach comes with very noticeable performance loss on most > of SSD devices and LUN's I have the opportunity to test it on. The fact is, > that bigger discard ranges are more efficient than smaller ones, so it make > sense try to batch the ranges together wherever it is possible. > > I have introduced new filesystem independent ioctl (FITRIM) which can be used > to send the "trim this portion of filesystem" command down to the filesystem > which (if implemented) discards all free extents in that range. > > The implementation for Ext3 and Ext4 is complete and you can see it here: > > http://www.spinics.net/lists/linux-ext4/msg21050.html > > Why I am sending it here to linux-fsdevel is because I am introducing new fs > independent ioctl and new member of super_operations (trim_fs) and we would > like let you know about this approach (which any filesystem can take > advantage from) and we would like your comment on this patch before we > send it upstream. My first question is: how do you test a filesystem implements ->trim_fs correctly? That is, if we are going to include a data-destroying ioctl, I really want some filesystem independent tests written first so that as filesystems implement ->trim_fs they can be tested for correct implementation. Perhaps adding FITRIM support to xfs_io, and a generic test to xfstests would be the way to go. e.g. write a set of patterned files to the filesystem, unlink a number of the files, then run some trim commands on the filesystem exercising corner cases and check that none of the data in still-active files is damaged (e.g. via md5sum comparison).... Cheers, Dave. -- Dave Chinner david@fromorbit.com