From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: uknown issues - different sha256 hash - files corruption
Date: Tue, 26 Jan 2016 16:51:02 +0000 (UTC) [thread overview]
Message-ID: <pan$63dba$aa63be34$a52be773$95f4b6bc@cox.net> (raw)
In-Reply-To: CAAcrkYJZnrFZKaEQQi6p48KHcGhkQh0LB_eC7xGAcNgFeLfTHA@mail.gmail.com
John Smith posted on Tue, 26 Jan 2016 15:32:21 +0100 as excerpted:
> i finished with testing and corruption (different hashes) happens only
> from lvm -> to btrfs, lvm -> lvm.
>
> Also i count sha256 on the same file on lvm 3x and i got 3 different
> hashes.
>
> Is it still hw issue or bug in LVM/ext4?
That does seem to clear btrfs, but it could be either ext4 or lvm, or
under the lvm at the physical volume level, and hardware is still a
possibility as well, tho rather less likely, as btrfs likely stresses the
hardware more than lvm or ext4.
The next question is whether it's the ext4 or lvm layer. There are two
ways to test it that I can think of.
One would be to run an sha256 hash test directly on the logical volume
the filesystem is normally created on (with the lvm assembled in read-
only mode and/or without the filesystem on top of it mounted or mounted
read-only). Does that return the same hash when run multiple times?
Obviously the problem there is the size of the logical volume; getting a
hash of the entire raw volume is likely to take some time. But this
should be the best test as it eliminates the filesystem from the equation
entirely.
Another alternative would be trying some filesystem other than ext4 on
the logical volume, say btrfs, xfs or reiserfs.
Either way, if the errors remain without ext4 being in the picture,
either because you're hashing the raw device or because you're using some
other filesystem, then that pretty well clears ext4. If the errors go
away, then heading to the ext4 list would probably be best, as ext4 would
seem to be the culprit.
If there's still errors at the logical volume device level, then the next
question is whether they appear on the raw physical volumes that the
logical volume is assembled out of, or not. Again, I'd suggest hashing
the raw devices repeatedly and see if they return the same hashes each
time. If not, then it's likely either the hardware or the device driver,
and you'd contact the device driver maintainer. (Here, I'd probably file
a bug on kernel bugzilla, YMMV.) If the raw physical devices hash
consistently while the LVM logical volume doesn't, then it's time to
contact the LVM folks.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2016-01-26 16:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-24 22:00 uknown issues - different sha256 hash - files corruption John Smith
2016-01-25 0:06 ` Patrik Lundquist
[not found] ` <CAAcrkY+3w--OGYWwben+KYohdqwBBryDn8REJ6tiBk4jM3Tp9w@mail.gmail.com>
2016-01-25 9:03 ` Patrik Lundquist
2016-01-25 16:53 ` John Smith
2016-01-25 22:02 ` Henk Slager
2016-01-26 0:15 ` John Smith
[not found] ` <CAAcrkYK7p1kFNS_p7s12Qv3Hafemq89hgocfa+DoX6Y15bXeBA@mail.gmail.com>
2016-01-26 11:58 ` John Smith
2016-01-26 11:59 ` John Smith
2016-01-26 11:54 ` John Smith
2016-01-26 12:23 ` Patrik Lundquist
2016-01-26 12:27 ` John Smith
2016-01-26 14:32 ` John Smith
2016-01-26 16:51 ` Duncan [this message]
2016-01-26 17:41 ` John Smith
2016-01-27 8:00 ` Duncan
2016-01-25 0:28 ` Duncan
2016-01-25 0:48 ` Chris Murphy
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='pan$63dba$aa63be34$a52be773$95f4b6bc@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).