From: kadafax@gmail.com
To: xfs@oss.sgi.com
Subject: Re: XFS, empty files after a crash
Date: Mon, 27 Feb 2012 09:43:42 +0100 [thread overview]
Message-ID: <4F4B423E.2000409@gmail.com> (raw)
In-Reply-To: <20120227010402.GR3592@dastard>
Le 27/02/12 02:04, Dave Chinner a écrit :
> On Tue, Feb 21, 2012 at 01:01:43PM +0100, kfx wrote:
>> # du myfile
>> 27460 myfile
>>
>> # du --apparent-size myfile
>> 0 myfile
>>
>> # xfs_bmap myfile
>> myfile: no extents
> That doesn't seem right:
>
> $ ls -l foobar
> -rw------- 1 root root 0 Feb 27 11:54 foobar
> $ du foobar
> 1024 foobar
> $ du --apparent-size foobar
> 0 foobar
> $ xfs_bmap foobar
> foobar:
> 0: [0..2047]: 255169872..255171919
>
> So xfs_bmap can and does report extents beyond EOF.
>
> du uses the fstat(2) syscall to get the block count from the inode,
> so it's seeing an inode with a block count but no extents. Can you
> dump the inode via xfs_db like so:
>
> $ ls -i foobar
> 604424233 foobar
> $ sudo xfs_db -r -c "inode 604424233" -c p /dev/md0
> core.magic = 0x494e
> core.mode = 0100600
> core.version = 2
> .....
>
> And post the output?
[root@server 1_out]# du foobar
25840 foobar
[root@server 1_out]# du --apparent-size foobar
0 foobar
[root@server 1_out]# xfs_bmap foobar
foobar: no extents
[root@server 1_out]# ls -i foobar
114748 foobar
[root@server 1_out]# xfs_db -r -c "inode 114748" -c p /dev/sdc1
core.magic = 0x494e
core.mode = 0100644
core.version = 2
core.format = 2 (extents)
core.nlinkv2 = 1
core.onlink = 0
core.projid = 0
core.uid = 12488
core.gid = 12488
core.flushiter = 0
core.atime.sec = Tue Jan 24 14:50:52 2012
core.atime.nsec = 609667096
core.mtime.sec = Tue Jan 24 14:50:53 2012
core.mtime.nsec = 579672930
core.ctime.sec = Tue Jan 24 14:50:53 2012
core.ctime.nsec = 579672930
core.size = 0
core.nblocks = 6460
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.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.filestream = 0
core.gen = 1924597489
next_unlinked = null
u.bmx[0] = [startoff,startblock,blockcount,extentflag]
0:[0,1881705728,6460,0]
After using the Nathaniel's advices and dd'ing the file:
[root@server recover]# ls -alh foobar
-rw-r--r-- 1 root root 26M Feb 24 10:39 /recover/foobar
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-02-27 8:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-21 12:01 XFS, empty files after a crash kfx
2012-02-21 16:25 ` Peter Grandi
2012-02-22 3:18 ` Eric Sandeen
2012-02-23 19:38 ` Nathaniel W. Turner
2012-02-23 20:07 ` kadafax
2012-02-23 22:15 ` Nathaniel W. Turner
2012-02-24 10:21 ` kadafax
2012-02-21 17:39 ` Stan Hoeppner
2012-02-27 1:04 ` Dave Chinner
2012-02-27 8:43 ` kadafax [this message]
2012-02-28 1:39 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F4B423E.2000409@gmail.com \
--to=kadafax@gmail.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox