public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: "Rebraca Dejan (BSOT/PJ-ES1-Bg)" <Dejan.Rebraca@rs.bosch.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: FIEMAP ioctl gets "wrong" address for the extent
Date: Mon, 6 Jul 2020 10:10:28 -0700	[thread overview]
Message-ID: <20200706171028.GA16070@vader> (raw)
In-Reply-To: <a18bcf27-4c65-6033-0ea7-45da2b521864@gmx.com>

On Thu, Jul 02, 2020 at 07:21:42PM +0800, Qu Wenruo wrote:
> 
> 
> On 2020/7/2 下午7:08, Rebraca Dejan (BSOT/PJ-ES1-Bg) wrote:
> > Hi Qu,
> > 
> > I'm using this structure to get the address of file extent:
> > 
> > struct fiemap_extent {
> > 	__u64	fe_logical;  /* logical offset in bytes for the start of
> > 			      * the extent */
> > 	__u64	fe_physical; /* physical offset in bytes for the start
> > 			      * of the extent */
> 
> fe_physical in btrfs is btrfs logical address.
> 
> > 	__u64	fe_length;   /* length in bytes for the extent */
> > 	__u64	fe_reserved64[2];
> > 	__u32	fe_flags;    /* FIEMAP_EXTENT_* flags for this extent */
> > 	__u32	fe_reserved[3];
> > };
> > 
> > And using fe_physical field I verified that it really reflects the offset in filesystem image - I can see that file content begins at this offset.
> > The problem is that I run into some specific case where file content doesn't begin at fe_physical, I rather have something else at this offset.
> 
> As said, there is no guarantee that btrfs logical address is mapped 1:1
> on disk.
> It's possible, but never guaranteed.
> 
> You need to pass that fe_physical number to btrfs-map-logical to find
> the real on-disk offset.
> 
> Thanks,
> Qu

FYI, I have a utility that does this mapping for all extents in a file:
https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c

$ sudo ./btrfs_map_physical archlinux-2020.07.01-x86_64.iso | column -ts $'\t'        
FILE OFFSET  FILE SIZE  EXTENT OFFSET  EXTENT TYPE  LOGICAL SIZE  LOGICAL OFFSET  PHYSICAL SIZE  DEVID  PHYSICAL OFFSET
0            6811648    0              regular      6815744       304680529920    6815744        1      89898610688
6811648      4096       0              regular      4096          304594616320    4096           1      89812697088
6815744      70250496   0              regular      70254592      419517255680    70254592       1      168228114432
77066240     4096       0              regular      4096          419587510272    4096           1      168298369024
77070336     127647744  0              regular      127647744     443648155648    127647744      1      209538883584
204718080    552960     0              regular      557056        304605401088    557056         1      89823481856
205271040    134217728  0              regular      134217728     491017764864    134217728      1      238654881792
339488768    43814912   0              regular      43814912      419587514368    43814912       1      168298373120
383303680    241664     0              regular      245760        304605958144    245760         1      89824038912
383545344    4096       0              regular      4096          304594620416    4096           1      89812701184
383549440    134217728  0              regular      134217728     517290700800    134217728      1      255264141312
517767168    78376960   0              regular      78381056      451287601152    78381056       1      213957103616
596144128    82284544   0              regular      82284544      517424918528    82284544       1      255398359040

  parent reply	other threads:[~2020-07-06 17:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-02  9:11 FIEMAP ioctl gets "wrong" address for the extent Rebraca Dejan (BSOT/PJ-ES1-Bg)
2020-07-02 10:18 ` Qu Wenruo
2020-07-02 11:08   ` Rebraca Dejan (BSOT/PJ-ES1-Bg)
2020-07-02 11:21     ` Qu Wenruo
2020-07-03  7:13       ` Rebraca Dejan (BSOT/PJ-ES1-Bg)
2020-07-06 17:10       ` Omar Sandoval [this message]
2020-07-02 11:43 ` David Sterba
2020-07-07  9:43   ` Anand Jain
2020-07-07 11:38     ` David Sterba

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=20200706171028.GA16070@vader \
    --to=osandov@osandov.com \
    --cc=Dejan.Rebraca@rs.bosch.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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