On 2025/6/29/Sun 20:25, Salvatore Bonaccorso wrote:
Control: tags -1 + moreinfo
Hi,
This is very odd, as there seem to be not ntfs3 related changes in the
changes between v6.12.32 and v6.12.33 (which was as well a very small
release).
A couple of things:
1. Can you please try as well 6.15.4-1~exp1 in experimental to verify if
you can trigger the issue there as well?
2. Can you please still do the following, but each kernel respective,
mount the NTFS volume and try to write to it. Then paste the full
dmesg you get for both 6.12.32-1 booted system and 6.12.33-1
bootest system.
3. If you feel confident, can you bisect the changes between 6.12.32 and
6.12.33 to pinpoint the commit which "breaks" so we might hopefully
be able to narrow down more closely the problem?
Regards,
Salvatore
Hi!
Thank you for your interest and response to this question.
I did some test and I want to apologize because from the results, I'm
not even quite sure if this is an issue that could be called a bug.
Overall, the problem, while it did occur after I upgraded my kernel to
6.12.33, *the direct link between the new version of the kernel and the
problem is not clear*.
Here is a brief dmesg message timeline related to ntfs3 from `journalctl
-k -b`. A bunch of messy nvidia-drm-related warning is omitted. I would
also like to apologize for failing to consult the logs from the previous
session when I filed this bug earlier.
```
|(Kernel upgraded from v6.12.32 to v6.12.33)
(v6.12.33 booted)
Jun 29 16:08:33 MyPC kernel: Linux version 6.12.33+deb13-amd64
([email protected])
(...)
(First observed error related to NTFS3 in dmesg)
(Before this, I had already experienced the IO write error issue and was
testing it.)
Jun 29 16:09:53 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:09:54 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:09:54 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:09:54 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:09:54 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:09:55 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:09:55 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:09:55 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:09:57 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:09:57 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:10:01 MyPC kernel: ntfs3: 16 callbacks suppressed
Jun 29 16:10:01 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:10:01 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:10:06 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:10:11 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
Jun 29 16:10:15 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect
seq=5 instead of 9!
(...)
(Some writing tests and fails, some reboots to Windows and previous
v6.12.32 kernel, but no related error recorded.)
(Thus it seems that not every occurred I/O write error or volume
mounting corresponds to a log error entry.)
(...)
(This bug was filed to Debian BTS.)
(...)
Jun 29 16:55:16 MyPC kernel: Linux version 6.12.33+deb13-amd64
([email protected])
(...)
Jun 29 16:56:53 MyPC kernel: ntfs3(nvme0n1p1): Mark volume as dirty due
to NTFS errors
Jun 29 16:57:13 MyPC kernel: ntfs3(nvme0n1p1): MFT: r=142228, expect
seq=5 instead of a!
(...)
Jun 29 21:01:19 MyPC kernel: Linux version 6.12.33+deb13-amd64
([email protected])
(...)
(First time I noticed this error in dmesg)
Jun 29 21:05:26 MyPC kernel: ntfs3(nvme0n1p1): Mark volume as dirty due
to NTFS errors
Jun 29 21:06:47 MyPC kernel: ntfs3(nvme0n1p1): MFT: r=142228, expect
seq=5 instead of 9!
(...)|
```
After the timeline above, I tried booting Windows and run the Disk Check
in Windows Explorer, and not surprisingly the tool thought there was an
error in this NTFS filesystem and fixed it.
After completing the fix, I've lived in harmony with this NTFS volume in
Debian so far without further problems, except that Windows Disk Check
removed some files I had written earlier to found.000.
I had been spending my time on Debian for about half a month before I
encountered this problem, so I can't for the moment think of an
opportunity to mess up the filesystem possibly due to Windows.
However, the precarious reproducibility of this problem now makes
locating it even more difficult. I think it's hard to say whether the
problem is due to a bug in kernel/ntfs3 or something else.
If possible, I will further test the experimental version of the kernel
at my convenience as you suggested, and report back further if I
encounter this issue again.
Thanks again for your help with this issue.
Best Regards,
dhao2001
