Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Window's build can't bind some files (big one) #231

Open
Namke opened this issue Aug 16, 2024 · 4 comments
Open

Window's build can't bind some files (big one) #231

Namke opened this issue Aug 16, 2024 · 4 comments
Labels
investigation Likely a can of worms

Comments

@Namke
Copy link

Namke commented Aug 16, 2024

I've made a dwarfs file with specs as follow, once it bind on Windows, dwarfs ran for few seconds then exit without any information (even with -v), the dwarfs checked was fine on Windows and bind successfully on Ubuntu. System have 96GB RAM available and won't occupied during binding.
Same issue with version 0.9.10 and 0.10
Screenshot 2024-08-16 at 23 00 06

@mhx
Copy link
Owner

mhx commented Aug 16, 2024

Wow, that's a pretty huge DwarFS image! :)

By "bind" I assume you mean "mount", i.e. you're trying to use the WinFSP/FUSE driver to mount the image?

Unfortunately I'm not an expert when it comes to Windows. But there's a few things you can try to see if we can narrow down this problem.

  • Please try using a Debug build. I've noticed in the past that Release build can just silently terminate in case of e.g. some assertion in the code. You can download a Debug build from the CI workflow: https://github.com/mhx/dwarfs/actions/runs/10423998579/artifacts/1821095156

  • Please try running:

    dwarfsck name-of-your-image.dwarfs --checksum=sha256
    

    This is different from running dwarfsck without --checksum in that it will actually access every single file and compute its checksum. Without --checksum, the image will only be checked to make sure it is valid on a block level. I don't think the image is the problem — as you said, it works fine on Linux — but checksumming all files is much closer to what the dwarfs driver does. So with this test, we can hopefully determine whether it's the DwarFS library or the WinFSP part that's causing the problem you're seeing.

  • Try increasing the debug level when running the driver:

    dwarfs name-of-your-image.dwarfs mountpoint -o debuglevel=trace
    

@Namke
Copy link
Author

Namke commented Aug 17, 2024

Hello there
The odd is this image work fine in Ubuntu, I always make check by dwarfsck after file creation and it was fine. Several file else with even bigger in size or larger in amount of files work fine (some not in Windows unfornatulaty, that why this issue).

And I made a bind with dwarfs.

Have added debug level trace into my command, and yeah this is an last log, seem something went wrong?

D 04:54:19.623042 [filesystem_v2.cpp:68] section num=14,878, type=METADATA_V2_SCHEMA, compression=ZSTD, length=465, checksum=0xf7a70c969e420ad0 [unknown], offset=117636066962 @ 117,636,066,962 [465 bytes]
D 04:54:19.623171 [filesystem_v2.cpp:68] section num=14,879, type=METADATA_V2, compression=ZSTD, length=25,522,612, checksum=0x0a6a2fe5ad04d039 [unknown], offset=117636067491 @ 117,636,067,491 [25,522,612 bytes]
D 04:54:20.537168 [filesystem_v2.cpp:68] section num=14,880, type=HISTORY, compression=ZSTD, length=303, checksum=0xf49d49bb38bcfd5c [unknown], offset=117661590167 @ 117,661,590,167 [303 bytes]
D 04:54:20.537313 [filesystem_v2.cpp:68] section num=14,881, type=SECTION_INDEX, compression=NONE, length=119,056, checksum=0x637d2a6efd3612ad [unknown], offset=117661590534 @ 117,661,590,534 [119,056 bytes]
D 04:54:20.639674 [string_table.cpp:70] imported dictionary for names string table [5us]
D 04:54:20.640129 [filesystem_v2.cpp:494] read 14,878 blocks and 55,692,356 bytes of metadata
I 04:54:20.641455 [dwarfs_main.cpp:1415] file system initialized [2.29s]
D 04:54:20.664613 [dwarfs_main.cpp:332] op_init_common
D 04:54:20.665073 [dwarfs_main.cpp:900] op_statfs(/)
D 04:54:20.665216 [dwarfs_main.cpp:450] op_getattr(/)
D 04:54:20.665573 [dwarfs_main.cpp:1009] op_getxattr(/, non-existant-a11ec902d22f4ec49003af15282d3b00, 1,024)
T 04:54:20.666346 [dwarfs_main.cpp:1022] op_getxattr: err=120

@mhx
Copy link
Owner

mhx commented Aug 17, 2024

D 04:54:20.665216 [dwarfs_main.cpp:450] op_getattr(/)
D 04:54:20.665573 [dwarfs_main.cpp:1009] op_getxattr(/, non-existant-a11ec902d22f4ec49003af15282d3b00, 1,024)
T 04:54:20.666346 [dwarfs_main.cpp:1022] op_getxattr: err=120

That looks normal, despite the err=120. This is apparently some internal check by WinFSP to see if extended attributes are supported.

However, this seems to be a hint that this could be an issue in WinFSP rather than DwarFS. For me, a log typically looks like this:

I 06:45:28.382266 [dwarfs_main.cpp:1415] file system initialized [54.76ms]
D 06:45:28.387741 [dwarfs_main.cpp:332] op_init_common
D 06:45:28.388044 [dwarfs_main.cpp:900] op_statfs(/)
D 06:45:28.388233 [dwarfs_main.cpp:450] op_getattr(/)
D 06:45:28.388573 [dwarfs_main.cpp:1009] op_getxattr(/, non-existant-a11ec902d22f4ec49003af15282d3b00, 1,024)
T 06:45:28.388825 [dwarfs_main.cpp:1022] op_getxattr: err=120
The service dwarfs has been started.

So very much like your log, but with the line The service dwarfs has been started. coming from WinFSP.

In between the the last two lines of my log, I believe only WinFSP code is running.

Did you try running dwarfs.exe from the debug build or running dwarfsck --checksum=sha256?

Also, which version of WinFSP are you using?

@Namke
Copy link
Author

Namke commented Aug 22, 2024

Hello,

I just finished checking with dwarfsck, it took a while:

  • Absolutely no issue on Ubuntu server
  • Its took little longer on Windows machine, but seem fine (I'm terminated it midway). This a little strange since this Machine is way stronger than old server box, I've disabled Windows Defender and there are no software interference.

The binding work absolutely fine on Ubuntu as well, I did binding, compare original with dwarfs one by Beyond Compare, exactly the same.

The WinFSP I installed were 2.00.23075, latest on their site I think.

Will try again on newly installed Windows machine and report back.

@mhx mhx added the investigation Likely a can of worms label Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
investigation Likely a can of worms
Projects
None yet
Development

No branches or pull requests

2 participants