From: "Patrick Shirkey" <pshirkey@boosthardware.com>
To: Ben Myers <bpm@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: file corruption issue
Date: Wed, 16 May 2012 04:30:47 +0200 (CEST) [thread overview]
Message-ID: <56000.110.174.53.110.1337135447.squirrel@boosthardware.com> (raw)
In-Reply-To: <20120515151331.GG16099@sgi.com>
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
> Unfortunately since you don't know which database will have the
> corruption...
> you'll need to get xfs_bmap output for all of them, and then after a crash
> get
> the 'after'. Is that a possibility?
>
I'll try to get some more data.
- Separately I was able to run xfs_metadump against one of our partitions.
The resulting file is 1.4 GB and it also has some potentially sensitive
information in it so I am not sure about posting it to a public location.
Is there anything that I can look for that might be useful.
I have some data from xfs_bmap on specific files located in the same
partition as the metadump was generated from. I'm not sure if that will
actually give us any details that can help though as this data is all post
crash atm.
- 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?
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.
--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-05-16 2:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-11 1:27 file corruption issue Patrick Shirkey
2012-05-11 16:50 ` Ben Myers
2012-05-14 1:45 ` Patrick Shirkey
2012-05-14 14:29 ` Ben Myers
2012-05-15 0:58 ` Patrick Shirkey
2012-05-15 15:13 ` Ben Myers
2012-05-16 2:30 ` Patrick Shirkey [this message]
2012-05-24 15:33 ` Ben Myers
2012-05-24 21:46 ` Patrick Shirkey
[not found] ` <20120601203451.32ae2ed5@asix.localdomain>
2012-06-01 12:38 ` Igor M Podlesny
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=56000.110.174.53.110.1337135447.squirrel@boosthardware.com \
--to=pshirkey@boosthardware.com \
--cc=bpm@sgi.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