From: Andreas Dilger <adilger@sun.com>
To: Mark Fasheh <mfasheh@suse.com>
Cc: linux-fsdevel@vger.kernel.org, Josef Bacik <jbacik@redhat.com>
Subject: Re: [PATCH 5/5] generic block based fiemap implementation
Date: Sun, 25 May 2008 02:00:51 -0600 [thread overview]
Message-ID: <20080525080051.GK3516@webber.adilger.int> (raw)
In-Reply-To: <20080525000235.GO8325@wotan.suse.de>
On May 24, 2008 17:02 -0700, Mark Fasheh wrote:
> +int ext3_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
> + u64 start, u64 len)
> +{
> + return generic_block_fiemap(inode, fieinfo, start, len,
> + ext3_get_block);
> +}
We can wire up ext2 in the same way, and likely most of the other filesystems.
#define GENERIC_FIEMAP_FLAG_SUPP (FIEMAP_FLAG_NUM_EXTENTS | FIEMAP_FLAG_SYNC |
FIEMAP_FLAG_HSM_READ | FIEMAP_FLAG_LUN_ORDER)
> +int generic_block_fiemap(struct inode *inode,
> + struct fiemap_extent_info *fieinfo, u64 start,
> + u64 len, get_block_t *get_block)
> +{
> + int just_count = fieinfo->fi_flags & FIEMAP_FLAG_NUM_EXTENTS;
Don't need this anymore.
if (fieinfo->fi_flags & ~GENERIC_FIEMAP_FLAG_SUPP) {
fieinfo->fi_flags &= ~GENERIC_FIEMAP_FLAG_SUPP;
return -EBADF;
}
> + /* HOLE */
> + if (!tmp.b_blocknr) {
> + if (length <= 0) {
> + if (just_count) {
> + fieinfo->fi_extents_mapped++;
> + break;
> + }
> + flags = FIEMAP_EXTENT_LAST;
> + ret = fiemap_fill_next_extent(fieinfo, logical,
> + phys, size,
> + flags, 0);
> + break;
Can remove the just_count check, fiemap_fill_next_extent() will handle it.
> + } else {
> + if (length <= 0 && size && !just_count) {
> + ret = fiemap_fill_next_extent(fieinfo, logical,
> + phys, size,
> + flags, 0);
> + if (ret)
> + break;
> + }
> +
> + logical = blk_to_logical(inode, start_blk);
> + phys = blk_to_logical(inode, tmp.b_blocknr);
> + size = tmp.b_size;
> + flags = 0;
> +
> + length -= tmp.b_size;
> + start_blk += logical_to_blk(inode, size);
> +
> + if (just_count) {
> + fieinfo->fi_extents_mapped++;
> + if (fieinfo->fi_extents_mapped ==
> + fieinfo->fi_extents_max)
> + break;
> + continue;
> + }
Can also remove this just_count check, which is incorrect in any case.
The fi_extents_max is only when storing extents in the array, it isn't
meaningful when only counting extents.
More important is the extent merging I proposed for fiemap_fill_next_extent()
for filesystems that only return single blocks, so we want to always
call it from the generic_block_fiemap() code.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
next prev parent reply other threads:[~2008-05-25 8:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-25 0:02 [PATCH 5/5] generic block based fiemap implementation Mark Fasheh
2008-05-25 8:00 ` Andreas Dilger [this message]
2008-05-27 17:51 ` Chris Mason
2008-05-28 15:31 ` Josef Bacik
2008-05-29 23:22 ` Andreas Dilger
2008-05-29 23:24 ` 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=20080525080051.GK3516@webber.adilger.int \
--to=adilger@sun.com \
--cc=jbacik@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mfasheh@suse.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;
as well as URLs for NNTP newsgroup(s).