You can also use the xfs_db command.
With this command you can walk the path ...
Do a help.
For example,
sb 0
p
prints the super block and you can see the root inode
number, usually 128.
inode 128
p
shows the inode and its contents. If the inode has all
the components, you will see these listed with their inode
#s and can then do
inode <new num>
p
Until you get there.
So, you could build a simple perl script that would use
xfs_db ...
xfs_db -r <dev>
If the log is dirty, problems. you could mount/unmout first
to make sure recovery ran and cleaned it up.
Enjoy,
Jim
If the inode/directory is in btree blocks, walking this
tree and find/printing all the blocks is left as an exercise
to the reader.
>
>> How complicated would it be to have a simple XFS reading program?
>>
>> Would this be an involved process? or something trivial?
>>
>> The reason I am asking is because of programs like grub and milo,
>> bootloaders
>> that actually read the filesystem to find the kernel (instead of
>> building a block map like lilo), and they would need updating before XFS
>> could take over as the primary filesystem for linux. ( A big goal, but
>> if the current XFS is of pre-beta quality, I can't wait for the actual
>> release )
>>
>> Thanks,
>> Rob
>>
>> (Flames may be sent directly, I like having one really good mailing list
>> out there)
>
>
>If you mean actually do the mapping from a path name to an inode and
>then get the file blocks without kernel support, then the amount of code
>involved is somewhat large - given the potential meta-data structures
>you might have to read to traverse a directory and then read in extents
>to figure out where the disk blocks are.
>
>There is also the issue of dealling witha filesystem which needs recovery
>running on it - the meta-data may not be consistent until that happens.
>
>However, ignoring the latter problem, take a look at the libsim library
>in cmd/xfs/sim/src - this is the XFS code built in user space for use
>by commands. There is still not enough code here - none of the
>user space tools do path name traversal, so the lookup code is not compiled
>in user space, although it would be possible to add this.
>
>However, given an inode number xfs_iget() gets you an inode, and xfs_bmapi
>retuns a mapping of file offsets to disk block numbers.
>
>xfs_logprint in cmd/xfs/logprint is probably the simplest user space
>command which opens a filesystem from user space - it would give
>you the infrastructure to make the calls to open the filesystem.
>
>
>
>Good Luck!
>
>Steve
>
>p.s. the xfs_bmap command contains an example of how to get the disk
>block locations for file data out of the kernel - I suspect this is
>what lilo would have to use.
>
|