From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Subject: Re: The VFS hot tracking debacle Date: Fri, 25 Jul 2014 09:43:17 +0100 Message-ID: <53D218A5.60308@redhat.com> References: <1383745544-391-1-git-send-email-zwu.kernel@gmail.com> <2831755.nuyKSN0E6B@merkaba> <20140717215248.GD20518@dastard> <5288000.xmdEPgGx6M@merkaba> <20140720000228.GK4453@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Poelzleithner , linux-fsdevel@vger.kernel.org To: Dave Chinner , Martin Steigerwald Return-path: Received: from mx1.redhat.com ([209.132.183.28]:23828 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759927AbaGYInq (ORCPT ); Fri, 25 Jul 2014 04:43:46 -0400 In-Reply-To: <20140720000228.GK4453@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi, On 20/07/14 01:02, Dave Chinner wrote: > On Fri, Jul 18, 2014 at 10:25:23AM +0200, Martin Steigerwald wrote: >> Am Freitag, 18. Juli 2014, 07:52:48 schrieb Dave Chinner: >>> On Thu, Jul 17, 2014 at 11:34:49PM +0200, Martin Steigerwald wrote: >>>> Am Donnerstag, 17. Juli 2014, 19:35:53 schrieb Daniel Poelzleithner: >>>>> Zhi Yong Wu gmail.com> writes: >>>>>> Ping ^ 7 >>>>> I'm following this patch now for quite some time and I have to say that >>>>> this thread+patch is one of the most disappointing experiences I had >>>>> with kernel development. >>>>> >>>>> I can't understand why such a patch is simply ignored from the >>>>> maintainers >>>>> of the subsystem, no comment, no review, no checkin. >>>> I always wanted to try this one out, but never got around doing it. >>>> >>>> I really like the general approach of it to put the general stuff into VFS >>>> and only the special stuff into filesystems like BTRFS. >>> And that's the core issue here: there are no applications that use >>> the information. i.e. it's a solution looking for a problem. >>> >>> I spent a lot of time reviewing and helping on this, and I made >>> repeated suggestions that applications like xfs_fsr could make use >>> of the information to do optimised file layout during >>> defragmentation, but nothing like that has ever been implemented. >>> >>> So, really, until there is an application that actually demonstrates >>> the usefulness of the specific information that is tracked and >>> exported, we can't verify that the code as it stands is actually >>> useful. We can verify that the code doesn't have problems, but we >>> can't verify whether it is fit for purpose because it currently has >>> no purpose.... >> So this needs an example implementation for one filesystem? >> >> I thought there is one for BTRFS. > The tracking of the "hot data" was implemented for both btrfs and > XFS. There isn't a *consumer* of that data, however, and that's the > missing piece of the picture. > > Cheers, > > Dave. GFS2 has both a producer (gfs2 tracepoints) and consumer (PCP pmda) of data which is intended to provide a picture of where there are hot spots in terms of cluster locking. The hot tracking patch set sounds like it should provide something similar on a generic basis, which I think should be a useful thing to have. I did look at some earlier versions of this patch set, but I rather lost track of it - is there an uptodate git tree somewhere? Steve.