From: Dave Chinner <email@example.com> To: "Theodore Y. Ts'o" <firstname.lastname@example.org> Cc: Mark Fasheh <email@example.com>, Carlos Maiolino <firstname.lastname@example.org>, "Darrick J. Wong" <email@example.com>, Eric Sandeen <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: Ext4 fiemap implementation Date: Wed, 13 Jun 2018 17:41:50 +1000 [thread overview] Message-ID: <20180613074150.GA19934@dastard> (raw) In-Reply-To: <20180613050453.GA3808@thunk.org> On Wed, Jun 13, 2018 at 01:04:53AM -0400, Theodore Y. Ts'o wrote: > On Wed, Jun 13, 2018 at 01:32:04PM +1000, Dave Chinner wrote: > > > Well, or the FIEMAP specs could be changed. If I recall correctly the > > > FIEMAP implementation by the various file systems predates the > > > documentation. I suspect whoever wrote the docs looked at the > > > ext2/ext3/ext4 implementation and used that to write the > > > documentation. If other file systems were doing something else, I'd > > > be in favor of allowing either behavior, since userspace programs who > > > care will need to accomodate either behavior. Fortunately, I suspect > > > it matters for very few (if any) userspace programs. > > > > The horse has bolted - we can't redefine the expected behaviour as > > that might break apps like cp (yes, it's still using FIEMAP for > > sparse file optimisations). > > As far as I know cp is working with the FIEMAP behavior as implemented > by ext4 and xfs w/o any problems. It is, apart from the inherent raciness of using FIEMAP to find holes and the fact that it won't detect cached data over unwritten extents.... > Given that ext4 and xfs have been > doing different things for a *very* long time now, in that sense the > horse has already bolted. There may be some applications that > expecting things the way ext4 has implemnted FIEMAP (and which is > either allowed or required by the documentation -- I read it as > mandated; others think it's a "you can do it either way"); and there > may be some applications that are expecting things the way XFS has > historically implemented FIEMAP. > > So my proposal was to change the docs to make it clear that Eric > Sandeen's reading (that either way is fine) is the correct > interpretation. Ok, we're saying the same things - it wasn't clear to me that your proposal was to document both behaviours as valid... Cheers, Dave. -- Dave Chinner email@example.com
next prev parent reply other threads:[~2018-06-13 7:42 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-06-01 12:36 Carlos Maiolino 2018-06-01 15:01 ` Eric Sandeen 2018-06-03 3:28 ` Theodore Y. Ts'o 2018-06-04 16:43 ` Darrick J. Wong 2018-06-06 13:13 ` Carlos Maiolino 2018-06-06 14:40 ` Darrick J. Wong 2018-06-07 8:31 ` Carlos Maiolino 2018-06-07 16:25 ` Darrick J. Wong 2018-06-08 8:18 ` Carlos Maiolino 2018-06-08 22:41 ` Mark Fasheh 2018-06-11 7:28 ` Carlos Maiolino 2018-06-12 23:52 ` Mark Fasheh 2018-06-13 3:06 ` Theodore Y. Ts'o 2018-06-13 3:32 ` Dave Chinner 2018-06-13 5:04 ` Theodore Y. Ts'o 2018-06-13 7:41 ` Dave Chinner [this message] 2018-06-13 12:09 ` Christoph Hellwig 2018-06-14 8:14 ` Carlos Maiolino 2018-06-01 18:57 ` Andreas Dilger
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180613074150.GA19934@dastard \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Ext4 fiemap implementation' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).