public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@sun.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Josef Bacik <jbacik@redhat.com>, linux-ext4@vger.kernel.org
Subject: Re: [RFC] FIEMAP on ext3
Date: Wed, 16 Apr 2008 21:40:24 -0600	[thread overview]
Message-ID: <20080417034024.GF3473@webber.adilger.int> (raw)
In-Reply-To: <48065391.10603@redhat.com>

On Apr 16, 2008  14:29 -0500, Eric Sandeen wrote:
> Josef Bacik wrote:
> > Obviously ext3 doesn't have extents, however it would still be usefull to use it
> > on sparse files in order to find data/holes within a file.  What I'm thinking is
> > treat contigous allocated blocks as an extent, and contiguous non-allocated
> > blocks as extents.  So for example, with Eric's fiemap test program, on a normal
> > non-sparse file you would only see one large extent for the entire file.  In the
> > case of a file that has data, hole and then data you would see 3 extents, two
> > for the two spans of data and one for the span of holes.
> > FIEMAP_FLAG_NUM_EXTENTS would in that case return 3.  Does this sound like an
> > acceptable thing to do?  If not, are there any other suggestions on how to do
> > fiemap in ext3?  Thanks much,

Well, this is already somewhat possible with "filefrag" though if you
want an API to do FIEMAP from applications (easier to program) I'd suggest
just having the fallback in glibc doing a loop of bmap ioctls.

Note that the updated filefrag tool we have for FIEMAP also allows a much
more useful output even for block-mapped files with the "-e" option.

> Yes, regardless of whether the fs itself manages blocks as "extents" you
> would just return contiguous ranges of blocks, allocated or unallocated,
> in the structures...
> 
> FWIW I think currently the definition says FLAG_NUM_EXTENTS only returns
> data extents not holes, so in your case above it'd be "2" (this bugs me
> a little)  :)

Well, if you really think that is important, feel free to complain now
rather than later.  We haven't landed the patch into Lustre yet, and I
agree it is inconsistent that we return 3 extents when we do a full scan
but 2 when we do NUM_EXTENTS...

> The current FIEMAP definition has enough other bells and whistles
> (flags), ext3 won't support most of them but that's ok; you won't have
> to mark blocks delalloc or unwritten or offline or ....

Right, for simple filesystem most of the flags can be ignored.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.


      reply	other threads:[~2008-04-17  3:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-16 19:10 [RFC] FIEMAP on ext3 Josef Bacik
2008-04-16 19:29 ` Eric Sandeen
2008-04-17  3:40   ` Andreas Dilger [this message]

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=20080417034024.GF3473@webber.adilger.int \
    --to=adilger@sun.com \
    --cc=jbacik@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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