public inbox for linux-bcachefs@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Steve Smith <tarkasteve@gmail.com>
Cc: linux-bcachefs@vger.kernel.org
Subject: Re: [bug]: fiemap returns zero extents for all files
Date: Tue, 5 Dec 2023 09:54:36 -0500	[thread overview]
Message-ID: <ZW85rKUfEXeaWqsL@bfoster> (raw)
In-Reply-To: <CAHLWS5EiGVn_-BFm2X1PKZ2m0EJq6VjckLdOuVqL2zWibxYUqA@mail.gmail.com>

On Tue, Dec 05, 2023 at 04:26:40PM +1100, Steve Smith wrote:
> Hi,
> 
> I'm doing some testing of xcp[1] against bcachefs, and having issues
> with fiemap. Using fiemap on both sparse and non-sparse files always
> returns `mapped_extents` of 0. The same tests on other extent-based
> FSs return non-zero extents, with consistent values. This is against
> -rc4 and master.
> 
> I've broken the relevant tests (in Rust) out into a standalone crate
> if you want to reproduce:
> 
>     https://github.com/tarka/bcachefs-test
> 
> The FS in question was created with a simple `bcachefs -L xcp-test /dev/sdh1`.
> 

Hi Steve,

Well I'm not really familiar with xcp or your test harness here, but
have you checked the results you're seeing against known working tools?
For example, one of the subtests just seems to perform a simple write
followed by an fiemap check/assert for a single extent. That is roughly
equivalent to:

# xfs_io -fc "pwrite 0 128k" -c "fiemap -v" ./file
wrote 131072/131072 bytes at offset 0
128 KiB, 32 ops; 0.0011 sec (108.790 MiB/sec and 27850.3046 ops/sec)
./file:
 EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
   0: [0..127]:        339968..340095     128   0x0
   1: [128..255]:      340096..340223     128   0x1

... which mostly seems to DTRT. I have noticed in the past that bcachefs
fiemap seems to break extents into bucket size or some such segments,
regardless of contiguity, but this doesn't seem to be the issue you are
reporting here. I.e. an strace of the above shows the following for the
fiemap ioctl():

ioctl(3, FS_IOC_FIEMAP, {fm_start=0, fm_length=18446744073709551615, fm_flags=FIEMAP_FLAG_SYNC, fm_extent_count=32} => {fm_flags=FIEMAP_FLAG_SYNC, fm_mapped_extents=2, ...}) = 0

... which shows fm_mapped_extents == 2. Hm?

Brian

> Cheers,
> Steve
> 
> [1]: https://github.com/tarka/xcp
> 


  reply	other threads:[~2023-12-05 14:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05  5:26 [bug]: fiemap returns zero extents for all files Steve Smith
2023-12-05 14:54 ` Brian Foster [this message]
2023-12-05 23:26   ` Steve Smith
2023-12-06 19:01     ` Brian Foster
2023-12-06 22:42       ` Kent Overstreet
2023-12-08 12:22         ` Brian Foster

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=ZW85rKUfEXeaWqsL@bfoster \
    --to=bfoster@redhat.com \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=tarkasteve@gmail.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