Re: uknown issues - different sha256 hash - files corruption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,
not sure if i have proper skill to do that LVM/ext4 test. I found this
- https://www.phoronix.com/scan.php?page=news_item&px=Linux-4-EXT4-RAID-Issue-Found

Maybe there is some connection?


On Tue, Jan 26, 2016 at 5:51 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote:
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux