From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Wed, 9 Jul 2008 03:03:05 +0100 Message-ID: <20080709020305.GC10728@shareable.org> 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> <48729267.6040604@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Chinner , linux-fsdevel@vger.kernel.org To: jim owens Return-path: Received: from mail2.shareable.org ([80.68.89.115]:44494 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751049AbYGICDI (ORCPT ); Tue, 8 Jul 2008 22:03:08 -0400 Content-Disposition: inline In-Reply-To: <48729267.6040604@hp.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: jim owens wrote: > Dave Chinner wrote: > > >The point of this SYNC flag is to ensure that you get nothing other > >than blocks mapped to disk - no delalloc regions, etc. The only sane > >way to do that is an atomic 'sync+map' operation. This is not a > >filesystem specific feature - it's what the SYNC flag should be > >defined as providing. > > If the real need is to force allocation then the flag should > be something like FIEMAP_FLAG_ALLOC and not need to do fsync > or any data flush, just ensure there is assigned storage. See also the huge time for fsync on ext3 in some circumstances (and why they had to patch Firefox 3 because of it). On ext3, FIEMAP_FLAG_ALLOC would be a no-op, but sync can take a long time. If the utilities using FIEMAP just need "no delalloc extents", they really should use an ALLOC flag, if only because forcing writeback, which may take a long time, is not what they are trying to accomplish. -- Jamie