From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A1D5C4BA3B for ; Thu, 27 Feb 2020 03:24:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 770092467B for ; Thu, 27 Feb 2020 03:24:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728260AbgB0DYt (ORCPT ); Wed, 26 Feb 2020 22:24:49 -0500 Received: from mail105.syd.optusnet.com.au ([211.29.132.249]:54469 "EHLO mail105.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728216AbgB0DYt (ORCPT ); Wed, 26 Feb 2020 22:24:49 -0500 Received: from dread.disaster.area (pa49-195-202-68.pa.nsw.optusnet.com.au [49.195.202.68]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id D45133A315B; Thu, 27 Feb 2020 14:24:44 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1j79n1-00069d-U2; Thu, 27 Feb 2020 14:24:43 +1100 Date: Thu, 27 Feb 2020 14:24:43 +1100 From: Dave Chinner To: Jan Kara Cc: "Darrick J. Wong" , Matthew Wilcox , Ritesh Harjani , tytso@mit.edu, linux-ext4@vger.kernel.org, adilger.kernel@dilger.ca, linux-fsdevel@vger.kernel.org, hch@infradead.org, cmaiolino@redhat.com Subject: Re: [PATCHv3 6/6] Documentation: Correct the description of FIEMAP_EXTENT_LAST Message-ID: <20200227032443.GI10737@dread.disaster.area> References: <279638c6939b1f6ef3ab32912cb51da1a967cf8e.1582702694.git.riteshh@linux.ibm.com> <20200226130503.GY24185@bombadil.infradead.org> <20200226161742.GB8036@magnolia> <20200226172653.GW10728@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200226172653.GW10728@quack2.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=X6os11be c=1 sm=1 tr=0 a=mqTaRPt+QsUAtUurwE173Q==:117 a=mqTaRPt+QsUAtUurwE173Q==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=l697ptgUJYAA:10 a=7-415B0cAAAA:8 a=UuCfLdhhvHlUIZ91etcA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Feb 26, 2020 at 06:26:53PM +0100, Jan Kara wrote: > On Wed 26-02-20 08:17:42, Darrick J. Wong wrote: > > On Wed, Feb 26, 2020 at 05:05:03AM -0800, Matthew Wilcox wrote: > > > On Wed, Feb 26, 2020 at 03:27:08PM +0530, Ritesh Harjani wrote: > > > > Currently FIEMAP_EXTENT_LAST is not working consistently across > > > > different filesystem's fiemap implementations and thus this feature > > > > may be broken. So fix the documentation about this flag to meet the > > > > right expectations. > > > > > > Are you saying filesystems have both false positives and false negatives? > > > I can understand how a filesystem might fail to set FIEMAP_EXTENT_LAST, > > > but not how a filesystem might set it when there's actually another > > > extent beyond this one. > > > > > > > * FIEMAP_EXTENT_LAST > > > > -This is the last extent in the file. A mapping attempt past this > > > > -extent will return nothing. > > > > +This is generally the last extent in the file. A mapping attempt past this > > > > +extent may return nothing. But the user must still confirm by trying to map > > > > +past this extent, since different filesystems implement this differently. > > > > "This flag means nothing and can be set arbitrarily by the fs for the lulz." > > > > Yuck. I was really hoping for "This is set on the last extent record in > > the dataset generated by the query parameters", particularly becaue > > that's how e2fsprogs utilties interpret that flag. > > The problem is that in some cases, we cannot determine whether the flag > should be set without doing work equivalent to another fiemap call. And it > just seems pointless to try to provide the flag in those cases. > > But I agree with Matthew that seeing the flag without the extent really > being the last one shouldn't happen (unless someone is changing the file). Which, of course, can happen. And it can even be the kernel (e.g. data writeback converting delalloc extents). IOWs, the information returned to userspace is out of date before it even gets to userspace, so userspace can't rely on the LAST flag to be correct in any situation. That's just an extension of the fact that userspace cannot rely on the extent map being correct and accurate in any situation.... Cheers, Dave. -- Dave Chinner david@fromorbit.com