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

Unnecessary checking of file after very first allocation of file #238

Open
antonsoroko opened this issue Jan 15, 2024 · 3 comments
Open

Comments

@antonsoroko
Copy link

For some reason, after first allocation of file BiglyBT also does full check of that file.
Maybe on some powerful device it is fast, so people does not notice this, but on Android TV box (2023, Amlogic S905X4 - which is the "latest" CPU for certified Android TV) + USB HDD exFAT (which is default for portable HDD use case) + big file (e.g. 10 GB) - this takes about 10 minutes. With 30GB file - it takes 30 minutes, which is not usable at all.

Would be nice to disable this check be default on "slow" devices or at least to have an option to manually disable this check. (I tried different "checking" related options - but none helped with this particular case).

Thank you.

@antonsoroko
Copy link
Author

Just a note for other users: there is the issue with is inability of exFAT FS to allocate "full" file - which means that it takes a lot of minutes to allocate file in a "incremental" manner. With formatting HDD to "internal" format (which used to be ext4, not sure about now) - this should not be an issue.

@antonsoroko
Copy link
Author

enabling "Enable incremental file creation [Required for FAT32 under Linux]" kind of mitigates this issue - since there is no full allocation - thus there is no check after full allocation.
but this still looks like a bug.
what is the point of checking file right after allocating it?

@Dimezis
Copy link

Dimezis commented Mar 21, 2024

I've encountered the same problem.

Incremental file creation does not help though, because if you're downloading a fragment of a file close to its end, it will have to allocate the file at least to that point.
The only real fix was to format the drive as internal, switching to ext4.
With that and "sparse files" it works fast.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants