From: Eric Sandeen <sandeen@sandeen.net>
To: Pradeep Kumar <praks411@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: 128 bits extent bmap for file format 2
Date: Tue, 22 Oct 2013 10:03:31 -0500 [thread overview]
Message-ID: <526693C3.3030505@sandeen.net> (raw)
In-Reply-To: <CAPU9cc3JXedegmC3MgzjtOaRLTtMZoT5C=gkS0zwTCySBqQhew@mail.gmail.com>
On 10/22/13 6:25 AM, Pradeep Kumar wrote:
> I was able to resolve the issue. This was indeed related to conversion between FSB to actual data block in image file. I would like to thanks Dave for showing the direction.
> So to summarize the extent data (128 bits, format =2) gives absolute block number which is in term of XFS file system block this need to be converted into actual disk block.
>
> I've used two macros for it.
> 1. #define XFS_FSB_TO_AGNO <http://lxr.free-electrons.com/ident?i=XFS_FSB_TO_AGNO>(mp,fsbno)
> 2.#define XFS_FSB_TO_AGBNO <http://lxr.free-electrons.com/ident?i=XFS_FSB_TO_AGBNO>(mp,fsbno).
>
> First one give the actual AG number and the second one gives the block number in that AG.
>
> Now coming back to my previous example which I posted
> My extent data was.
> 00 00 00 00 00 00 00 00 00 00 00 04 99 80 00 01 (LSB)
>
> After unpacking, absolute block number = 9420 (0x24cc).
> Converting to actual data block using above two macros gives me AG No. = 1, AG Block No = 1228. So final block (1*6400 + 1228 = 7628) which is correct.(I was able to get correct file contents)
> Please let me know if above computation is correct. It seems correct to me as I'm able to retrieve all the files.
>
> Still I couldn't get two macros.
> 1. #define XFS_FSS_TO_BB <http://lxr.free-electrons.com/ident?i=XFS_FSS_TO_BB>(mp,sec <http://lxr.free-electrons.com/ident?i=sec>) ((sec <http://lxr.free-electrons.com/ident?i=sec>) << (mp)->m_sectbb_log).
> *2. *#define XFS_BB_TO_FSBT <http://lxr.free-electrons.com/ident?i=XFS_BB_TO_FSBT>(mp,bb <http://lxr.free-electrons.com/ident?i=bb>) ((bb <http://lxr.free-electrons.com/ident?i=bb>) >> (mp)->m_blkbb_log).
>
> I couldn't find m_sectbb_log and m_blkbb_log fields. Please someone share more knowledge on above
> macros like where they are used and also description of input and output field
Use the source, Luke:
[linux-2.6]$ grep m_blkbb_log fs/xfs/*.h
fs/xfs/xfs_mount.h: __uint8_t m_blkbb_log; /* blocklog - BBSHIFT */
linux-2.6]$ grep m_sectbb_log fs/xfs/*.h
...
fs/xfs/xfs_mount.h: __uint8_t m_sectbb_log; /* sectlog - BBSHIFT */
it's the log of the (block/sector) size, minus the basic block (512) shift (9)
/*
* Block I/O parameterization. A basic block (BB) is the lowest size of
* filesystem allocation, and must equal 512. Length units given to bio
* routines are in BB's.
*/
#define BBSHIFT 9
-Eric
> Thanks and Regards,
> Pradeep
>
>
>
>
>
> On 22 October 2013 10:08, Pradeep Kumar <praks411@gmail.com <mailto:praks411@gmail.com>> wrote:
>
> Hi Dave,
>
> Thanks for the reply. I think I may get my solution. Can you explain the difference between the two?
> I've created sample xfs file using mkfs.xfs with mostly default parameter
> 1. Sector Size = 512
> 2. Block size = 4096
> 3. AG Number = 2
> 4. Number of blocks per AG = 6400.
>
> So when I get absolute block 9420 from file extent data I'm going to (6400 + 3020) , 3020 block of second AG which is wrong. The file start from 7628 absolute block or (6400 + 1228), 1228 block of second AG.
> Please describe in some detail above the conversion which you are talking about.
>
> Thanks and Regards,
> Pradeep
>
>
>
> On 22 October 2013 02:12, Dave Chinner <david@fromorbit.com <mailto:david@fromorbit.com>> wrote:
>
> On Tue, Oct 22, 2013 at 01:32:22AM +0200, Pradeep Kumar wrote:
> > Hi,
> >
> > I'm writing a small utility to parse XFS fs image on windows.
> > I'm able to fetch the files in the first AG (0).
> > However when it comes to the files which are in different AG I'm facing
> > some problem in parsing extent bmap 128bits data of file inode (format ==
> > 2).
>
> Extents use filesystem block encodings, not disk addresses. Look up
> the macros XFS_DADDR_TO_FSB and XFS_FSB_TO_DADDR.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com <mailto:david@fromorbit.com>
>
>
>
>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-10-22 15:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 23:32 128 bits extent bmap for file format 2 Pradeep Kumar
2013-10-22 0:12 ` Dave Chinner
2013-10-22 8:08 ` Pradeep Kumar
2013-10-22 11:25 ` Pradeep Kumar
2013-10-22 15:03 ` Eric Sandeen [this message]
2013-10-22 13:11 ` Greg Freemyer
2013-11-03 5:20 ` Pradeep Kumar
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=526693C3.3030505@sandeen.net \
--to=sandeen@sandeen.net \
--cc=praks411@gmail.com \
--cc=xfs@oss.sgi.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