From: Andreas Dilger <adilger@sun.com>
To: Josef Bacik <jbacik@redhat.com>
Cc: Mark Fasheh <mfasheh@suse.com>, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 5/5] generic block based fiemap implementation
Date: Thu, 29 May 2008 17:22:27 -0600 [thread overview]
Message-ID: <20080529232227.GK2985@webber.adilger.int> (raw)
In-Reply-To: <20080528153112.GA23090@unused.rdu.redhat.com>
On May 28, 2008 11:31 -0400, Josef Bacik wrote:
> Signed-off-by: Josef Bacik <jbacik@redhat.com>
> +/*
> + * @inode - the inode to map
> + * @arg - the pointer to userspace where we copy everything to
> + * @get_block - the fs's get_block function
> + *
> + * This does FIEMAP for block based inodes. Basically it will just loop
> + * through get_block until we hit the number of extents we want to map, or we
> + * go past the end of the file and hit a hole.
> + *
> + * If it is possible to have holes and data past EOF then please don't use
> + * this function, it will do wrong things.
> + */
I think it would be clearer to write at the end "If it is possible to have
data blocks beyond a hole past @inode->i_size, then please do not use this
function, it will stop at the first unmapped block beyond i_size."
> +int generic_block_fiemap(struct inode *inode,
> + struct fiemap_extent_info *fieinfo, u64 start,
> + u64 len, get_block_t *get_block)
> +{
> + struct buffer_head tmp;
> + unsigned int start_blk;
> + long long length = 0, map_len = 0;
> + u64 logical = 0, phys = 0, size = 0;
> + u32 flags = 0;
> + int ret = 0;
> +
> + start_blk = logical_to_blk(inode, start);
> +
> + /* guard against change */
> + mutex_lock(&inode->i_mutex);
> +
> + length = (long long)min_t(u64, len, i_size_read(inode));
> + map_len = length;
> +
> + do {
> + /*
> + * we set b_size to the total size we want so it will map as
> + * many contiguous blocks as possible at once
> + */
> + memset(&tmp, 0, sizeof(struct buffer_head));
> + tmp.b_size = map_len;
> +
> + ret = get_block(inode, start_blk, &tmp, 0);
> + if (ret)
> + break;
Shouldn't map_len be reduced as the file is traversed? Otherwise the
filesystem may be doing a lot more work than it needs to for block mapping
if the requested length is not the whole file. If, for example, the first
1GB of the file is requested (map_len = 2 << 30) and 1022MB are mapped, the
last 1MB get_block() request will still request 1GB mapping.
It isn't a major problem (only a corner case really), and the map_len
can't be exactly the same as "length", because it still needs to be
positive after EOF so that blocks will continue to be mapped.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
next prev parent reply other threads:[~2008-05-29 23:22 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
2008-05-27 17:51 ` Chris Mason
2008-05-28 15:31 ` Josef Bacik
2008-05-29 23:22 ` Andreas Dilger [this message]
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=20080529232227.GK2985@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).