On 7/20/20 11:24 AM, Hans van Kranenburg wrote:
Hi,
On Wed, 15 Jul 2020 20:52:40 -0700 Sarah Newman <s...@prgmr.com> wrote:
On 7/7/20 8:13 PM, Ben Hutchings wrote:
Control: reassign -1 src:linux
Control: tag -1 moreinfo
On Tue, 2020-07-07 at 17:30 -0700, Sarah Newman wrote:
Package: linux-signed-amd64
Version: 4.19.0-9-amd64
We've had two separate reports now of debian buster users running
4.19.0-9-amd64 who experienced serious file system corruption.
Which version? (I.e. what does "uname -v" or
"dpkg -s linux-image-4.19.0-9-amd64" say?)
- Both were using ext3
- Both are running Xen HVM, but I do not have reason to believe this to be
related
[...]
I have servers which run 4.19.118-2 as dom0 kernel and a Xen 4.11.4-1
rebuild for Buster.
One example is a smallish 6-server cluster that got a reboot cycle 48
days ago.
It contains a few heavily loaded domUs with 4.19.118 or 4.19.131 based
kernels.
No problems or disk corruption or anything is seen yet. dom0 filesystem
is ext4, domUs use a mix of ext4 and btrfs (over iscsi). So, no ext3
anywhere.
We haven't got bug reports against Debian Xen packages in the BTS about
this.
I have not yet tried to make an ext3 fs on a block device in a test domU
and then have it do things with the fs and reboot it now and then. If
wanted, I can do that and see if there's any problem after a week or
two. Just to add chaos to help correlating.
FWIW,
Hans
We've had 9 reports of users running 4.19.0-9-amd64 total, only 2 with ext3, no uptimes longer than maybe 5 weeks for the ext3 + 4.19.0-9-amd64 users.
No more reported failures.
Our attempts to reproduce so far have not been successful, but that might be because we were running a debug kernel build and I think there may have
been a deadlock in between depot_lock and console_owner which killed the tests.
I'm not sure what the next steps are here, but it sounds like ext4 has not
shown any problems.
--Sarah