xfs
[Top] [All Lists]

Re: XFS, empty files after a crash

To: xfs@xxxxxxxxxxx
Subject: Re: XFS, empty files after a crash
From: "Nathaniel W. Turner" <nate@xxxxxxxxxxxxxxx>
Date: Thu, 23 Feb 2012 17:15:23 -0500
In-reply-to: <4F469C7F.9020208@xxxxxxxxx>
References: <4F4387A7.2070009@xxxxxxxxx> <20291.50554.414722.399249@xxxxxxxxxxxxxxxxxx> <4F445E9F.5030003@xxxxxxxxxxx> <4F4695B1.4060202@xxxxxxxxxxxxxxx> <4F469C7F.9020208@xxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
On 02/23/2012 03:07 PM, kadafax@xxxxxxxxx wrote:

kfx, try getting the inode number of the file (via stat or ls -i) and then doing something like this:

xfs_db -r $DEV -c "inode $INO" -c "bmap"


# xfs_db -r /dev/sdc1 -c "inode 114748" -c "bmap"
data offset 0 startblock 1881705728 (7/2657536) count 6460 flag 0

# xfs_db -r /dev/sdc1 -c "inode 114754" -c "bmap"
data offset 0 startblock 1077794560 (4/4052736) count 6582 flag 0

If you want to see what's behind those data extents (which are probably partially written), you could do something along these lines:

# Determine the AG size
agblocks=$(xfs_db -r /dev/sdc1 -c sb -c p | grep ^agblocks | sed 's/.* = //')

# Copy the extent in the first file, which consists of 6460 blocks (~26MB)
# in AG 7 starting at AG-relative block 2657536:
dd if=/dev/sdc1 bs=4096 skip=$(($agblocks * 7 + 2657536)) count=6460 of=./blob
# examine ./blob
...

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