xfs
[Top] [All Lists]

more efficient way to print out inode->block mappings?

To: xfs-oss <xfs@xxxxxxxxxxx>
Subject: more efficient way to print out inode->block mappings?
From: Linda Walsh <xfs@xxxxxxxxx>
Date: Thu, 27 Sep 2012 04:39:35 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666
I want to be able to rapidly determine the diffs between 2 volumes.

Special note 1 is an active lvm snapshot of the other -- meaning it is
frozen in time, but otherwise should look identical the the file system
as it was when it was snapped.

Sooo... a way of speeding checks is finding out what blocks allocated to the 
indoes
are different, since as the new volume gets used, I had hoped that differing
block numbers might give me a clue as to what had changed..

I'm thinking though, that the block numbers that will change will be the ones
in lvm -- not xfs.  So this probably isn't as useful as i'd hoped.

Nevertheless, trying to read the blocks allocated/inode with bmap is sorta slow.
I've tried to optimize it by starting a pty session to xfs_db and issuing 
inode/bmap
commands -- but I have to wait for a prompt to come back to know that the 
command
has finished, and I'm not really sure it's really returning more than 1 line
for any file. -- though interactively, I can find a file with a large ACL, and 
see
it has both a data and attr bmap.  I also haven't seen what output would look 
like
if the file(or dir) was split -- as, so far, have only seen files/dirs returned that
have 1 allocation/file,

So what the means is that I'm not sure about synchronization between commands 
output
and the input I read in -- even though I read in the input after every command. -- but even with a minimal timeout of 1ms, and keeping track of commands outstanding and replies (as measured by 'prompts' recieved, I'm far from convinced it's doing the right thing -- and it still
slow going 1 inode at a time over a pty interface.

I thought of trying to use blockget -v and parsing the output. I figured that would
have the least latency and likely be the fastest way to dump the mappings -- BUT
it seems I can't get it to work on an active file system. So how can I get that block info dumped without blockget? I've already told blockget it's in -r only mode... so it shouldn't try to repair inconsistencies...and 99.999% is going to be what I want and any inconsistencies, I can check manually be checking the files through the mounted interface.

Oddly, and likely I'm confused about something, but when i try to print the log/log_print,
it says it is an invalid log 1 byte long, so even if it were played out, I don't
think it would make much difference in the final results.

Is it possible to do what I want w/o writing a special util/C prog to dump this?

<Prev in Thread] Current Thread [Next in Thread>