From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Fri, 4 Jul 2008 09:00:01 +1000 Message-ID: <20080703230001.GC29319@disturbed> References: <20080625221835.GQ28100@wotan.suse.de> <486CE430.9010902@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org, mfasheh@suse.com To: jim owens Return-path: Received: from ipmail01.adl6.internode.on.net ([203.16.214.146]:6305 "EHLO ipmail01.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755857AbYGCXAE (ORCPT ); Thu, 3 Jul 2008 19:00:04 -0400 Content-Disposition: inline In-Reply-To: <486CE430.9010902@hp.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Jul 03, 2008 at 10:37:36AM -0400, jim owens wrote: > As Jamie pointed out, this: > I disagree with these: > >> * FIEMAP_EXTENT_SECONDARY >> The data for this extent is in secondary storage (e.g. HSM). If the >> data is not also in the filesystem, then FIEMAP_EXTENT_NO_DIRECT >> should also be set. =2E... > Or, as was said before, maybe HSM should wait until we > know what it really needs. Given that other flags for HSM interfacing have already been removed (i.e. the 'don't recall HSM resident extents to map them' flag) this serve=D1=95 little purpose. As to what HSM needs, we know exactly what it needs - that's one of the things XFS has been working intimately with for years and years. Those needs fed into the original fiemap interface design and this flag was one of them (as was the 'don't read' flag that has already been removed). Cheers, Dave. --=20 Dave Chinner david@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html