From: Eric Sandeen <sandeen@redhat.com>
To: Andreas Dilger <adilger@sun.com>
Cc: Mark Fasheh <mfasheh@suse.com>, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 4/5] ext4: implement ext4_fiemap
Date: Sun, 25 May 2008 10:26:34 -0500 [thread overview]
Message-ID: <4839852A.5040902@redhat.com> (raw)
In-Reply-To: <20080525075139.GJ3516@webber.adilger.int>
Andreas Dilger wrote:
> On May 24, 2008 17:02 -0700, Mark Fasheh wrote:
>> +#define EXT4_FIEMAP_FLAG_INCOMPAT_UNSUPP (FIEMAP_FLAG_INCOMPAT & \
>> + ~(FIEMAP_FLAG_LUN_OFFSET))
>
> Per discussion with Eric, this needs to be changed:
>
> #define EXT4_FIEMAP_FLAG_SUPP (FIEMAP_FLAG_NUM_EXTENTS | FIEMAP_FLAG_SYNC | \
> FIEMAP_FLAG_HSM_READ | FIEMAP_FLAG_LUN_ORDER)
>
Yep, I agree with this and the others, probably should have put "proof
of concept" in the original message; I knew it had warts but didn't want
to hold up Mark's RFE.
Thanks Andreas,
-Eric
>> +struct fiemap_internal {
>> + struct fiemap *fiemap_s;
>> + struct fiemap_extent fm_extent;
>> + char *cur_ext_ptr;
>> + int err;
>> +};
>
> This is no longer used and can be removed (now uses fiemap_extent_info).
>
>> +/*
>> + * Callback function called for each extent to gather FIEMAP information.
>> + */
>> +int ext4_ext_fiemap_cb(struct inode *inode, struct ext4_ext_path *path,
>> + struct ext4_ext_cache *newex, struct ext4_extent *ex,
>> + void *data)
>> +{
>> + /* Just counting extents? */
>> + if (fieinfo->fi_flags & FIEMAP_FLAG_NUM_EXTENTS) {
>> + fieinfo->fi_extents_mapped++;
>> + return EXT_CONTINUE;
>> + }
>
> This isn't needed anymore, fiemap_fill_next_extent() handles it.
>
>
>> +int ext4_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
>> + __u64 start, __u64 len)
>> +{
>> + /* fallback to generic here if not extents */
>> +#warning fix bitmap fallback
>> + if (!(EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL))
>> + return -EOPNOTSUPP;
>
> if (!(EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL))
> return generic_block_fiemap(inode, fieinfo, start, len,
> ext4_get_block);
>
>> +#if 0
>> + /* bail on unsupported flags for this fs */
>> + if (fiemap_s->fm_flags & EXT4_FIEMAP_FLAG_INCOMPAT_UNSUPP)
>> + return -EOPNOTSUPP;
>> +#endif
>
> This should be reinstated now that we have come to a decision on the flags:
>
> if (fieinfo->fi_flags & ~EXT4_FIEMAP_FLAG_SUPP) {
> fieinfo->fi_flags &= ~EXT4_FIEMAP_FLAG_SUPP;
> return -EBADF;
> }
>
>
> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
>
prev parent reply other threads:[~2008-05-25 15:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-25 0:02 [PATCH 4/5] ext4: implement ext4_fiemap Mark Fasheh
2008-05-25 7:51 ` Andreas Dilger
2008-05-25 15:26 ` Eric Sandeen [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=4839852A.5040902@redhat.com \
--to=sandeen@redhat.com \
--cc=adilger@sun.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).