@hal_pomeranz Whilst I'm waiting for your part six on the XFS stuff, would you mind if I asked you a question about the b+tree directory structures?
1
Fire away -- if it's too big for Twitter, email me
1
Which email is best? Thanks
1
They all end up at “hal at deer-run dot com”
1
Thanks, email is en-route. Hopefully it makes sense. I've been starting at this stuff for too long now and I'm beyond confused :)
1
My reply should have hit your inbox
1
It has indeed, thanks for that. I do have one more question, if you have time. Still a bit unsure as to how the offset of zero has been calculated into the address shown in xfs_db?
1
There's only one chunk at the next level of the tree, so it has to be at logical offset zero from the start of the directory file.
1
Ok, understood. I guess what is confusing me still is where the value 0x004081A1 came from. It's not in the inode anywhere, so why is that address being used to store the directory file, when all that's in the inode is a logical offset? Thanks
1
Replying to @mrthaggar
Sent you another email--the explanation was too long for Twitter

Apr 16, 2019 · 4:48 PM UTC

2
Replying to @hal_pomeranz
Awesome, thank you very much!
Replying to @hal_pomeranz
Seems what was throwing me was the length of the arrays. I assumed they were dynamically sized, so I was seeing zero, and zero. Is the number of entries in there in the documentation somewhere, I couldn't see it.
1
Each array length is simply half of the available space between the end of inode core and the beginning of the extended attributes (or end of the inode if no resident attributes)
1
more replies