linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Fasheh <mfasheh@suse.com>
To: Andreas Dilger <adilger@sun.com>
Cc: linux-fsdevel@vger.kernel.org, Josef Bacik <jbacik@redhat.com>
Subject: Re: [PATCH 1/5] vfs: vfs-level fiemap interface
Date: Wed, 28 May 2008 14:23:59 -0700	[thread overview]
Message-ID: <20080528212359.GF8325@wotan.suse.de> (raw)
In-Reply-To: <20080528194215.GI7263@webber.adilger.int>

On Wed, May 28, 2008 at 01:42:15PM -0600, Andreas Dilger wrote:
> > > What about the idea to have fiemap_fill_next_extent() do "extent" merging
> > > for filesystems that use the generic helper but do not return multiple
> > > blocks via get_blocks()?  I don't think that is too hard to implement,
> > > and makes the output more useful, otherwise we get an extent per block.  
> > > The above is what I _think_ will work, haven't actually tried it out.
> > 
> > I don't think we want to automatically merge extents within this helper
> > function. Otherwise we would diverge from the actual disk layout for extent
> > based file systems where an extent might be broken up between two records
> > for some other reason, such as maximum extent length being exceeded.
> 
> Do we really want to expose the filesystem-specific extent-length limits
> to userspace?

Think of it more as being as literal in our representation of extents as
possible. My max extent length was just a (poor) example, meant to
illustrate that goal.

A better one is extent merging. The Ocfs2 btree code tries pretty hard to
merge adjacent extents when they're contiguous. I want to use fiemap in a
tool to measure how good a job the extent merging code is doing, especially
after we've made bug fixes or enhancements to that area. If the vfs starts
to hide these important details from fiemap, then that use case becomes
impossible.


> In some sense, a block-based filesystem has a maximum extent length of the
> blocksize, but it seems totally reasonable to merge contiguous blocks into
> a single "extent" for return to userspace. I don't see this significantly
> different for ext4, even though it can have extents up to 128MB, or
> unwritten extents up to 64MB.

I don't know what the answer is for a block based file system. I do know
however that we have a compatibility callback there for them and that's the
place to implement any block-fs specific features that we want.
	--Mark

--
Mark Fasheh

  parent reply	other threads:[~2008-05-28 21:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-25  0:01 [PATCH 1/5] vfs: vfs-level fiemap interface Mark Fasheh
2008-05-25  7:28 ` Andreas Dilger
2008-05-27 18:31   ` Mark Fasheh
2008-05-28 16:09     ` Andreas Dilger
2008-05-28 17:24       ` Joel Becker
2008-05-29 23:46         ` Andreas Dilger
2008-05-30  0:15           ` Mark Fasheh
2008-05-30 17:24             ` Andreas Dilger
2008-05-28 19:42 ` Andreas Dilger
2008-05-28 19:54   ` Josef Bacik
2008-05-28 20:12     ` Mark Fasheh
2008-05-28 20:19       ` Josef Bacik
2008-05-28 21:23   ` Mark Fasheh [this message]
2008-05-29  1:24   ` Dave Chinner
2008-05-29 13:04     ` Christoph Hellwig
2008-05-29 17:02       ` Andreas Dilger
2008-05-31  8:16         ` Christoph Hellwig
2008-05-29 13:03   ` Christoph Hellwig
2008-06-05  5:18 ` Andreas Dilger
2008-06-05 21:35   ` jim owens

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=20080528212359.GF8325@wotan.suse.de \
    --to=mfasheh@suse.com \
    --cc=adilger@sun.com \
    --cc=jbacik@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).