| To: | xfs@xxxxxxxxxxx |
|---|---|
| Subject: | Re: XFS, empty files after a crash |
| From: | "Nathaniel W. Turner" <nate@xxxxxxxxxxxxxxx> |
| Date: | Thu, 23 Feb 2012 14:38:25 -0500 |
| In-reply-to: | <4F445E9F.5030003@xxxxxxxxxxx> |
| References: | <4F4387A7.2070009@xxxxxxxxx> <20291.50554.414722.399249@xxxxxxxxxxxxxxxxxx> <4F445E9F.5030003@xxxxxxxxxxx> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 |
On 02/21/2012 10:18 PM, Eric Sandeen wrote: I'd agree that there is likely nothing to recover; there are no extents allocated. I'm not sure why du is reporting space used though. I have noticed that xfs_bmap (which uses the ioctl bmap interface) will not report extents after EOF. There probably *are* extents allocated to this file, but they are not being reported by xfs_bmap. 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" This will dump the entire extent map, and I suspect you'll see at least one extent. nate |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [PATCH 4/4] V2 xfs: fix deadlock in xfs_rtfree_extent with kernel v2.6.37, Kamal Dasu |
|---|---|
| Next by Date: | Re: XFS, empty files after a crash, kadafax |
| Previous by Thread: | Re: XFS, empty files after a crash, Eric Sandeen |
| Next by Thread: | Re: XFS, empty files after a crash, kadafax |
| Indexes: | [Date] [Thread] [Top] [All Lists] |