Arch Linux

nyanpasu64

Member

Registered: 2021-11-07

Posts: 2

Full system hang when Digikam writes to SQLite on ntfs3 mount

I'm running linux-zen 5.18.7.zen1-1. (I know it's outdated, but I don't want to reproduce this bug on an updated kernel since I'm afraid of disk corruption.)

I've been using digiKam without incident for a few days, with the SQLite files located on a SSD partition (alongside my Linux boot partition) mounted using Linux's in-kernel ntfs3 driver, and the images themselves located on a ntfs3 partition on a *separate* mechanical disk. Today I accidentally imported two copies of hundreds of images, so I tried deduplicating images which required first building a digiKam similarity database. During the process, Linux hung entirely, not responding to Alt-SysRq shortcuts (which is highly unusual). After rebooting, there was no hang/crash message in the journal, with the last entries being:

Jul 07 03:09:21 ryzen digikam[20528]: digikam.metaengine: Cannot load metadata from file with Exiv2 backend: /mnt/storage/digikam/moto-g5>
Jul 07 03:09:21 ryzen digikam[20528]: digikam.metaengine: Cannot parse metadata from [ "/mnt/storage/digikam/moto-g5+/Download/fljucsmale>
Jul 07 03:09:21 ryzen digikam[20528]: digikam.metaengine: Cannot load metadata from file with Exiv2 backend: /mnt/storage/digikam/moto-g5>

After rebooting, ntfs3 wouldn't mount both NTFS partitions:

Jul 07 03:18:33 ryzen kernel: ntfs3: nvme0n1p6: volume is dirty and "force" flag is not set!

Rebooting to Windows, chkdsk said my storage disk was clean, but the sqlite disk "Found 0x1 clusters allocated to file "\digikam\similarity.db <0x1,0x5440>" at offset "0xe4" marked as free".

I suspect digiKam hit a ntfs3 kernel crash, or perhaps instead an infinite loop or mutex deadlock. SQLite does a lot of unusual filesystem operations, like locking files and flushing data, and I wonder if these operations on ntfs3 can occasionally trigger an deadlock. (either that, or merely reading files from my photo disk hung the kernel, which I find less likely.)

Is this a known Linux bug? Should it be reported upstream? I'm thinking of converting both disks to btrfs in-place using ntfs2btrfs (after taking a backup), then using winbtrfs to access them on Windows.