From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [PATCH] vfs: Add a trace point in the mark_inode_dirty function Date: Wed, 11 Nov 2009 02:56:29 -0500 Message-ID: <4AFA6E2D.7010709@garzik.org> References: <20091025225342.007138f5@infradead.org> <20091111020108.GA11423@localhost> <20091110223456.01ef355f@infradead.org> <4AFA6AEF.5060306@garzik.org> <20091111074542.GB25132@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 To: Ingo Molnar Return-path: In-Reply-To: <20091111074542.GB25132@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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... :) Jeff