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: Tue, 8 Jul 2008 13:01:20 +1000 Message-ID: <20080708030120.GP29319@disturbed> References: <20080625221835.GQ28100@wotan.suse.de> <1214489061.6237.16.camel@norville.austin.ibm.com> <4863A483.5060303@redhat.com> <1214490465.6237.24.camel@norville.austin.ibm.com> <486C13B7.4030402@hp.com> <20080703111726.GZ29319@disturbed> <486CC1FA.10003@hp.com> <20080703225124.GB29319@disturbed> <487287C2.5090309@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: jim owens Return-path: Received: from ipmail01.adl6.internode.on.net ([203.16.214.146]:11946 "EHLO ipmail01.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755926AbYGHDBY (ORCPT ); Mon, 7 Jul 2008 23:01:24 -0400 Content-Disposition: inline In-Reply-To: <487287C2.5090309@hp.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Jul 07, 2008 at 05:16:50PM -0400, jim owens wrote: > Dave Chinner wrote: > >> Why? Have you ever used an extent mapping interface before? > > YES - for the past 9 years in Tru64 unix. > > Interfaces that were used by tools to defragment, print extmaps, > capture metadata for support, > perform backups > with directIO through the fs, move file extents between devices, Those are simple 'give me a mapping' cases - syncing first is appropriate for all those cases. Making it atomic so you only get blocks mapped to disk is also appropriate for all these cases.... > scan for fs errors, Deep filesystem specific knowledge is needed to do that properly, so it's not really a use case we've considered for a generic fiemap API. > allow a stacked cluster filesystem to read/write directly to > the raw device from other Tru64 nodes, Oh, that's just gross. > allow an IBM Tivoli client > to read/write directly to the raw SAN storage from anywhere, > (and probably some uses I've forgot). yes, that's a fairly common thing to do from a read-only snapshot of the filesystem. IOWs, the filesystem image is not changing so - block mapping is stable - no concurrent modifications The application has provided sane access synchronisation to the blocks, so it's not needed in fiemap. Great - your an expert in storage and you know that your application doesn't need use the FIEMAP_FLAG_SYNC.... > What I have been trying to point out in the fiemap discussion > is all learned from past mistakes. You're saying that like it's a bad thing. Learning from mistakes is how we improve things. Cheers, Dave. -- Dave Chinner david@fromorbit.com