xfs
[Top] [All Lists]

RE: UPDATE: low-level XFS drive recovery

To: Chris Bednar <cjb@xxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: UPDATE: low-level XFS drive recovery
From: Stephen Lord <lord@xxxxxxx>
Date: 24 Apr 2002 17:07:21 -0500
Cc: "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.10.10204241446590.8135-100000@alpha2.production.mnd.com>
References: <Pine.LNX.4.10.10204241446590.8135-100000@alpha2.production.mnd.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Wed, 2002-04-24 at 14:59, Chris Bednar wrote:
> 
>     I'm not asking if such a tool exists for XFS, mind you, but sooner
> or later, given that we have a few TB of XFS in house, I can guess that
> I'll want to know if the info to do this still exists on the platter,
> and if I could get it through xfsprogs-devel...
> 
> 
> ----
> Chris J. Bednar
> Director, Distributed Computing Product Group
> http://AdvancedDataSolutions.com/

Getting stuff back in XFS is always problematical, it is so good at
cleaning up after itself. With some filesystems, once you get to an
inode, getting the data back is not too hard. With XFS, when you
delete a file, the extents which were in that file are removed from
it and returned to free space, destroying the record in the inode 
of where the data once was.

Curtis (who worked on XFS at one point) has come the closest here,
xfs_logprint can dump out the contents of the log, and at least
provide a record of what happened most recently. Unfortunately,
the options on logprint which format the contents also do similar
processing to mount - the find the head and tail of the log, and
if is empty (as it will be after a successful unmount), proceed
to print nothing:

# xfs_logprint -t /dev/hda3
xfs_logprint:
    data device: 0x303
    log device: 0x303 daddr: 4193024 length: 131072

    log tail: 88508 head: 88508 state: <CLEAN>

xfs_db is also a good tool for looking at metadata:

xfs_db /dev/xxx
xfs_db: inode 132
xfs_db: p
core.magic = 0x494e
core.mode = 0100664
core.version = 1
core.format = 2 (extents)
core.nlinkv1 = 1
core.uid = 858
core.gid = 858
core.atime.sec = Mon Apr  1 07:04:31 2002
core.atime.nsec = 706933000
core.mtime.sec = Mon Apr  1 06:54:42 2002
core.mtime.nsec = 086933000
core.ctime.sec = Mon Apr  1 06:54:42 2002
core.ctime.nsec = 086933000
core.size = 4119297
core.nblocks = 1006
core.extsize = 0
core.nextents = 1
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.gen = 25
next_unlinked = null
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,1664,1006,0]

I can even get to the data:

xfs_db: dblock 0
xfs_db: p
000: 534d426d 6b646972 20524551 55455354 20506174 68205c43 4c49454e 54530a53
020: 4d426d6b 64697220 5245504c 59200a53 4d426d6b 64697220 52455155 45535420
040: 50617468 205c4e42 53494d55 4c440a53 4d426d6b 64697220 5245504c 59200a53
060: 4d426d6b 64697220 52455155 45535420 50617468 205c4e42 53494d55 4c445c43
080: 4c49454e 540a534d 426d6b64 69722052 45504c59 200a534d 426d6b64 69722052

But if I delete the inode and go look at it again:

xfs_db: inode 132
xfs_db: p
core.magic = 0x494e
core.mode = 0
core.version = 1
core.format = 2 (extents)
core.nlinkv1 = 0
core.uid = 858
core.gid = 858
core.atime.sec = Mon Apr  1 07:04:31 2002
core.atime.nsec = 706933000
core.mtime.sec = Mon Apr  1 06:54:42 2002
core.mtime.nsec = 086933000
core.ctime.sec = Wed Apr 24 16:47:02 2002
core.ctime.nsec = 665733000
core.size = 0
core.nblocks = 0
core.extsize = 0
core.nextents = 0
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.gen = 26
next_unlinked = null
u = (empty)

All the extent info got wiped out in the formated output. I can get
raw output:

xfs_db: type data
xfs_db: p
00: 494e0000 01020000 0000035a 0000035a 00000000 00000000 00000000 00000000
20: 3ca85adf 2a22f108 3ca85892 052e7e08 3cc727d6 27ae4788 00000000 00000000
40: 00000000 00000000 00000000 00000000 00000002 00000000 00000000 0000001a
60: ffffffff 00000000 00000000 00000000 d00003ee 00000000 00000200 00000000
80: 02c00002 00000000 00000600 00000000 05000001 00000000 00000800 00000000
a0: 07000002 00000000 00000c00 00000000 00000000 00000059 00000000 00000000
c0: 01a00001 00000001 00000200 00000000 06400002 00000001 00000600 00000000
e0: 09600001 00000002 00000000 00000000 05200001 00000000 00000000 00000000


The extent information may actually still be there in this case, but it is
getting pretty hard to get at.

In answer to the original question in this thread, there is a good chance
the files are reasonably sequential on the disk, if they were written one
at a time, but there is no guarantee of this, and no real simple way of
finding out.

Sorry I am not being more helpful here.

Steve



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