I am parsing XFS from an XFS formatted partition.
Formatted and maintained by an old Buffalo NAS.
The 128 BYTE extent contains three parts, the amount of file-system blocks, the absolute address and an offset in the file (to be able to track sparse extents).
It's the latter that gives me unexpected results.
From the documentation I found (a 'Silicon Graphics Inc.' pdf file) it is suggested that the Offset is in bytes. However I find that it is in file system blocks !
- Any idea what it should be (bytes of blocks) ? For the sake of future parsing.
- Perhaps I missed a flag I need to check that signifies either bytes or blocks (can't find it) ?
- Is it XFS version depending ? I'm looking at v5 specs (I would expect the pdf to mention this then though)
- A Buffalo NAS proprietary implementation perhaps ?
Let me know if you know )
I am not sure to follow you.
An XFS extent is 128 BITs (not bytes) and all addresses are in blocks, not bytes, according to this
http//
(Chapter 15, page 100)
Or you are talking of something else?
jaclaz
Indeed, I meant 128 bits, not bytes. My mistake.
I am using the same document.
What confuses me is the actual (raw data) example on page 103
The field clearly contains actual bytes, not blocks.
Given this 'real life ?' example I figured that's the proper way to interpret page 100
Indeed, I meant 128 bits, not bytes. My mistake.
I am using the same document.
What confuses me is the actual (raw data) example on page 103
The field clearly contains actual bytes, not blocks.
Given this 'real life ?' example I figured that's the proper way to interpret page 100
All references on page 103 are also for blocks.
Maybe is the lack of colour that is confusing?
…
80 58 e0 07 e9 00 00 00 00 00 1f a4 00 00 00 00 11
90 53 20 07 e9 00 00 00 00 00 00 00 00 00 00 00 00
…
We can expand the highlighted section into the following bit array fromMSB to LSB with the fle ofset and the block
count highlighted
127-96 0000 0000 0000 0000 0000 0000 0000 0000
95-64 0000 0000 0001 1111 1010 0100 0000 0000
63-32 0000 0000 0000 0000 0000 0000 0000 1111
31-0 0101 1000 1110 0000 0000 0111 1110 1001Grouping by highlights we get
file offset = 0x0fd2 (4050)
start block = 0x7ac7 (31431)
block count = 0x07e9 (2025)
The data is converted into binary (i.e. bits) and then re-grouped as the actual fields.
jaclaz
I'm talking about the Offset (the red highlighted bit in your post)
In the XFS file system I'm parsing, this field contains values 0, 1, 2, 3, … and so on.
To arrive at the actual amount in bytes I have to multiply it by the file system block size (e.g. 4096).
In the example a true byte value is present, not a value that needs to be multiplied by the file system block size.
I'm talking about the Offset (the red highlighted bit in your post)
Ok. )
In the XFS file system I'm parsing, this field contains values 0, 1, 2, 3, … and so on.
To arrive at the actual amount in bytes I have to multiply it by the file system block size (e.g. 4096).
…which is seemingly compatible with the specs … ?
In the example a true byte value is present, not a value that needs to be multiplied by the file system block size.
I don't understand. (
4050 is a number, it means (per the specs) the "logical" block offset.
How can you say that 4050 is a byte offset and not a block offset?
jaclaz
OMG
This happens when you work on a Sunday while in fact you should be resting.
core.size = 24883200
core.nblocks = 6075
For whatever reason I 'saw' that the file was 6075 bytes (not blocks) and correlated the Offset from that, hence my confusion. But the file is 6075 blocks in size … not bytes.
Of course I could have seen this when looking at the amount of blocks per extent but I was too focussed on offset (tunnel vision).
All good … XFS makes sense again.
All good … XFS makes sense again.
Good )
https://
"Five to one against and falling…" she said, "four to one against and falling…three to one…two…one…probability factor of one to one…we have normality, I repeat we have normality." She turned her microphone off—then turned it back on, with a slight smile and continued "Anything you still can’t cope with is therefore your own problem."
wink
jaclaz