Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757389AbZKKLPp (ORCPT ); Wed, 11 Nov 2009 06:15:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756342AbZKKLPo (ORCPT ); Wed, 11 Nov 2009 06:15:44 -0500 Received: from mx2.mail.elte.hu ([157.181.151.9]:52741 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753800AbZKKLPn (ORCPT ); Wed, 11 Nov 2009 06:15:43 -0500 Date: Wed, 11 Nov 2009 12:15:35 +0100 From: Ingo Molnar To: Jeff Garzik Cc: Arjan van de Ven , Wu Fengguang , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Christoph Hellwig , Al Viro , Frederic Weisbecker , auke-jan.h.kok@intel.com Subject: Re: [PATCH] vfs: Add a trace point in the mark_inode_dirty function Message-ID: <20091111111535.GA25325@elte.hu> References: <20091025225342.007138f5@infradead.org> <20091111020108.GA11423@localhost> <20091110223456.01ef355f@infradead.org> <4AFA6AEF.5060306@garzik.org> <20091111074542.GB25132@elte.hu> <4AFA6E2D.7010709@garzik.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AFA6E2D.7010709@garzik.org> User-Agent: Mutt/1.5.20 (2009-08-17) X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1185 Lines: 33 * Jeff Garzik wrote: > On 11/11/2009 02:45 AM, Ingo Molnar wrote: > > > >* Jeff Garzik wrote: > > > >>On 11/11/2009 01:34 AM, Arjan van de Ven wrote: > >>>Wu Fengguang wrote: > >>>>Maybe this is enough for POWERTOP, however for general use, the dirty > >>>>type(data/metadata) and inode number may be valuable to some users? > >>> > >>>what can a user do with an inode number???? > >> > >>Inode numbers have always been visible to userspace... IIRC, tar(1) > >>uses the st_ino member of struct stat to detect hard links in certain > >>cases. ls(1) displays inode numbers with -i, find(1) looks for them > >>with -inum, ... > > > >Without an inode->vfs-name lookup/matching service it's of limited > >utility > > Look in the quoted text for one such service... :) I'm not sure i understand your point - do you really suggest using find(1) to make traces readable? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/