[Bug 201685] ext4 file system corruption

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=201685

--- Comment #151 from Jimmy.Jazz@gmx.net ---
(In reply to Jens Axboe from comment #149)

> You had the issue with the full block patch applied, the one that includes
> both the synchronize_rcu() and the quiesce? Or just the partial one I
> suggested earlier?

synchronize_rcu() and the quiesce as you asked me.


> Interesting, so it didn't make it to media.

The following tests has be made on an other computer named orca to not be
confused with earlier comments I have posted.

Again, I can confirm it but only with your patches applied. On orca with 4.20
and w/o your patch the bug was able to entirely wipe out orca postgres database
:(

It gives me the opportunity to do a full reinstall of orca from the stick.
Don't get confused with mmp_node_name host name on the new created partitions,
it has an easy explanation. The bootable stick used to create the filesystems
has a different hostname than the final server (i.e. orca)

Please read the attached bug.orca.tar.xz tar file. You can follow the logs
sequence from the file creation time.

I underline, the new corruption on dm-10 after the server has rebooted has
nothing to do with the one announced  earlier in dmesg. Read dmesg-zalman.txt,
dmesg-zalman-2.txt and dumpe2fs-dm-10-after-e2fsk.txt, dmesg-after-e2fsk.txt in
that order. It shows that dm-10 corruption was initiate during the reboot.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.