[Bug 1198669] New: Unable to fully read some files with ntfs3
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669 Bug ID: 1198669 Summary: Unable to fully read some files with ntfs3 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: linus.kardell@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I'm trying out the ntfs3 kernel driver on OpenSUSE Tumbleweed, but I'm unable to read some files. I also posted about this here: https://reddit.com/r/openSUSE/comments/u693vm/no_such_file_or_directory_when... , and at https://bugzilla.kernel.org/show_bug.cgi?id=215864 The files that it happens to are a few GiB in size. It doesn't fail immediately, rather when I read it with dd status=progress the first time it reads a bit into the file (a few MiB or over a hundred MiB, depending on the files, but it seems to always be the same distance for the same file), and then throws "No such file or directory". On subsequent reads, it gets through the whole file. Only, it doesn't really, because the resulting content is wrong. It's the correct length, but past a certain point the it's all zeroes. So it never truly reads the whole file, but only sometimes throws an error (when it's not in disk cache?). The same file always comes out correct with ntfs-3g. Also, not sure if related, but after I've mounted and unmounted a few times with ntf3 and ntfs-3g, ntfs3 starts throwing errors saying: "mount: /windows/d: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error." and refuses to mount it unless I add -o ro. ntfs-3g still mounts it, and ntfs3 mounts it after rebooting. The filesystem has compression enabled, in case that matters (though the files should be incompressible, as they're gzipped). I tried running chkdsk from Windows, but that did not change anything. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669#c4
--- Comment #4 from Linus Kardell
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669#c5
Linus Kardell
which exact kernel version are you using with the ntfs3 driver
I'm on kernel 5.17.2-1-default
which (Windows) OS version was used to create the NTFS read data?
The filesystem was created by Windows 10, but the files were written to it by ntfs-3g. Don't remember the exact versions.
what kind of compression was enabled? NTFS appears to support a few different types
Not sure exactly, or how to check. I just enabled "Compress this drive to save disk space" for the file system in Windows, and let it go through the filesystem and compress the contents. Then I used the "compression" mount option when mounting with ntfs-3g. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669#c6
--- Comment #6 from David Disseldorp
which exact kernel version are you using with the ntfs3 driver
I'm on kernel 5.17.2-1-default
which (Windows) OS version was used to create the NTFS read data?
The filesystem was created by Windows 10, but the files were written to it by ntfs-3g. Don't remember the exact versions.
Was the ntfs-3g version performing the write also on tumbleweed, i.e. ~2021.8.22?
what kind of compression was enabled? NTFS appears to support a few different types
Not sure exactly, or how to check. I just enabled "Compress this drive to save disk space" for the file system in Windows, and let it go through the filesystem and compress the contents. Then I used the "compression" mount option when mounting with ntfs-3g.
Thanks for the extra detail, this should be enough for an attempt at reproducing this. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669#c7
--- Comment #7 from Linus Kardell
Was the ntfs-3g version performing the write also on tumbleweed, i.e. ~2021.8.22?
Yes, it was on Tumbleweed. Don't remember when exactly I wrote the file I tested with earlier, but I was able to reproduce it again now with ntfs-3g 2021.8.22-2.2, by dd:ing 4 GiB of /dev/urandom to a file and copying it onto the NTFS partition with ntfs-3g, and then trying to read with ntfs3. My full mount options btw are: ntfs-3g: fmask=113,dmask=002,gid=100,noatime,windows_names,compression ntfs3: iocharset=utf8,fmask=113,dmask=002,gid=100,noatime -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669#c8
--- Comment #8 from David Disseldorp
Created attachment 858358 [details] debug.trace
It looks as though the I/O failure is coming from a spurious ENOENT in the read path: ... read(0, "r\377\350X\3305j\2217\251\1\311\\\326(\307\7e\363'#\307\344!P\221\211h\34*\307\236"..., 512) = 512 write(1, "r\377\350X\3305j\2217\251\1\311\\\326(\307\7e\363'#\307\344!P\221\211h\34*\307\236"..., 512) = 512 read(0, "D\234J\321\256\313\262\332\32\350\352\236Rg\253\300p\254t\205\235=\205g\322M\n}\372\302\0I"..., 512) = 512 write(1, "D\234J\321\256\313\262\332\32\350\352\236Rg\253\300p\254t\205\235=\205g\322M\n}\372\302\0I"..., 512) = 512 read(0, 0x5585832ea000, 512) = -1 ENOENT (Filen eller katalogen finns inte) Wading through the ntfs3 file read code-path there appear to be a handful of ENOENT return sites, with the (IMO) most probable being in the compression specific attr_wof_frame_info() path: #ifdef CONFIG_NTFS3_LZX_XPRESS /* Read header of Xpress/LZX file to get info about frame. */ attr_wof_frame_info() attr_load_runs_range(type=ATTR_DATA, name=WOF_NAME) attr_load_runs_vcn() ->attr = ni_find_attr(ni, NULL, NULL, type, name, name_len, &vcn, NULL); if (!attr) { /* Is record corrupted? */ return -ENOENT; } .. ntfs_bio_pages() if (!run_lookup_entry(run, vcn, &lcn, &clen, &run_idx)) { err = -ENOENT; ... } if (!run_get_entry(run, ++run_idx, &vcn, &lcn, &clen) || vcn != vcn_next) { err = -ENOENT; I'll work on preparing some ftrace instructions to profile some of the above call sites. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669#c9
--- Comment #9 from Linus Kardell
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669
http://bugzilla.opensuse.org/show_bug.cgi?id=1198669#c10
--- Comment #10 from Linus Kardell
I'll work on preparing some ftrace instructions to profile some of the above call sites.
Did anything come of this? -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com