Re: FIEMAP ioctl gets "wrong" address for the extent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux