On Wed, May 16, 2012 at 04:30:47AM +0200, Patrick Shirkey wrote:
> On Tue, May 15, 2012 5:13 pm, Ben Myers wrote:
> > On Tue, May 15, 2012 at 02:58:42AM +0200, Patrick Shirkey wrote:
> >> Unfortunately I cannot unmount the partition/s to run xfs_metadump because
> >> they are in use.
> >> I have found some files that were truncated on a recent crash. Is there
> >> any tool I can run on those files to get info that might be useful?
> > Hrm.. xfs_bmap output could be helpful so we can see the block map. Do you
> > know how big they are supposed to be? How much was truncated?
> The files that we have as examples were originally 28bytes but are now 0byte.
> Running xfs_bmap on the 0 byte file returns "no extent".
> These files are located next to each other in the same folder.
> - 28 byte file: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET
> TOTAL 0: [0..7]: 28230136440..28230136447 13 (312849120..312849127)
> - 0 byte file: no extents
So how old are the files that get truncated? Were they created very recently?
> - A few more details that may be relevant.
> 1: We are running openvz and LVM on these machines. Are there any known
> issue/s with file corruption after a hard reset with openvz/LVM running?
I don't know about openvz/LVM...
> 2: We have observed that while there is no obvious pattern in the data
> corruption is does happen in chunks. It appears to be random chunks of files
> that are corrupted after a crash->reset sequence.
...and the data corruption happened in files that are read only? Again.. when
were they created?