Hey Patrick, 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". > > ex. > > 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) > 8 > > - 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? Thanks, Ben _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs