https://bugzilla.kernel.org/show_bug.cgi?id=201685 --- Comment #151 from Jimmy.Jazz@xxxxxxx --- (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.
