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
(debian-kernel@lists.debian.org)
(...)
(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
(debian-kernel@lists.debian.org)
(...)
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
(debian-kernel@lists.debian.org)
(...)
(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