starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Torrents don't pre-allocate properly #5798

New issue

Closed

opened 2026-02-21 18:03:17 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-21 18:03:17 -05:00

Owner

Originally created by @DerekTurtleRoe on GitHub (Jul 19, 2017).

qBittorrent version and operating system:

OS: 64-bit Windows 10 Enterprise
qBittorrent 3.3.14 64-bit
Qt: 5.9.1
Libtorrent: 1.0.11.0
Boost: 1.64.0

What is the problem:

Torrent files downloaded via magnet links or torrent files don't allocate the space needed for download properly

What is the expected behavior:

All the space needed should be allocated when the download starts, otherwise the point of pre-allocating is somewhat defeated.

Steps to reproduce:

Make sure pre-allocation of files is on
Download any torrent file, or use a magnet link
Start downloading file
Check download location to confirm that the pre-allocation doesn't match total torrent download size

Extra info

I have "Enable OS cache" on, which is the default setting.

Originally created by @DerekTurtleRoe on GitHub (Jul 19, 2017). ### qBittorrent version and operating system: OS: 64-bit Windows 10 Enterprise qBittorrent 3.3.14 64-bit Qt: 5.9.1 Libtorrent: 1.0.11.0 Boost: 1.64.0 ### What is the problem: Torrent files downloaded via magnet links or torrent files don't allocate the space needed for download properly ### What is the expected behavior: All the space needed should be allocated when the download starts, otherwise the point of pre-allocating is somewhat defeated. ### Steps to reproduce: 1. Make sure pre-allocation of files is on 2. Download any torrent file, or use a magnet link 3. Start downloading file 4. Check download location to confirm that the pre-allocation doesn't match total torrent download size ### Extra info I have "Enable OS cache" on, which is the default setting.

deekerman closed this issue

2026-02-21 18:03:20 -05:00

deekerman commented

2026-02-21 18:03:23 -05:00

Author

Owner

@Seeker2 commented on GitHub (Jul 20, 2017):

Known problem...previous issue examples of it:
Disk space is only pre-allocated when files start dl'ing https://github.com/qbittorrent/qBittorrent/issues/6195
...and mentioned here: https://github.com/qbittorrent/qBittorrent/issues/6421
Pre-allocate disk space for all files doesn't work https://github.com/arvidn/libtorrent/issues/2074

This was all caused by a previous request:
Make the "Preallocate" option behave in a sane manner https://github.com/qbittorrent/qBittorrent/issues/1072

@Seeker2 commented on GitHub (Jul 20, 2017): Known problem...previous issue examples of it: Disk space is only pre-allocated when files start dl'ing https://github.com/qbittorrent/qBittorrent/issues/6195 ...and mentioned here: https://github.com/qbittorrent/qBittorrent/issues/6421 Pre-allocate disk space for all files doesn't work https://github.com/arvidn/libtorrent/issues/2074 This was all caused by a previous request: Make the "Preallocate" option behave in a sane manner https://github.com/qbittorrent/qBittorrent/issues/1072

deekerman commented

2026-02-21 18:03:23 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jul 20, 2017):

Thanks @Seeker2. I didn't have all the info available.

@sledgehammer999 commented on GitHub (Jul 20, 2017): Thanks @Seeker2. I didn't have all the info available.

deekerman commented

2026-02-21 18:03:23 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jul 20, 2017):

PS: I closed it because this "works as designed". This is libtorrent feature. qbt can't fix it.

@sledgehammer999 commented on GitHub (Jul 20, 2017): PS: I closed it because this "works as designed". This is libtorrent feature. qbt can't fix it.

deekerman commented

2026-02-21 18:03:23 -05:00

Author

Owner

@DerekTurtleRoe commented on GitHub (Jul 20, 2017):

@sledgehammer999 They seem like they don't want to fix it, so I guess I will just disable it for now. Thanks for the help, anyway.

@DerekTurtleRoe commented on GitHub (Jul 20, 2017): @sledgehammer999 They seem like they don't want to fix it, so I guess I will just disable it for now. Thanks for the help, anyway.

deekerman commented

2026-02-21 18:03:23 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jul 20, 2017):

@vgturtle127 you do realize that the moment each file starts downloading it will be preallocated? Do you really need preallocation for ALL files before download starts? If a torrent is quite big it will take minutes before it can start due to preallocation.

@sledgehammer999 commented on GitHub (Jul 20, 2017): @vgturtle127 you do realize that the moment **each** file starts downloading it will be preallocated? Do you really need preallocation for ALL files before download starts? If a torrent is quite big it will take minutes before it can start due to preallocation.

deekerman commented

2026-02-21 18:03:23 -05:00

Author

Owner

@DerekTurtleRoe commented on GitHub (Jul 20, 2017):

@sledgehammer999 It is something I prefer, since I usually download smaller things (as in, under 7GB). Most of it is LibreOffice releases and Linux distributions, so huge 100+GB torrents are not super commonplace for me.

I also have limited space on my SSD, so being aware of how much space I have left is nice. It can be a hassle.

I see what you're saying, though. I just wish it was an option.

@DerekTurtleRoe commented on GitHub (Jul 20, 2017): @sledgehammer999 It is something I prefer, since I usually download smaller things (as in, under 7GB). Most of it is LibreOffice releases and Linux distributions, so huge 100+GB torrents are not super commonplace for me. I also have limited space on my SSD, so being aware of how much space I have left is nice. It can be a hassle. I see what you're saying, though. I just wish it was an option.

deekerman commented

2026-02-21 18:03:23 -05:00

Author

Owner

@Seeker2 commented on GitHub (Jul 21, 2017):

Zero-filling on pre-allocate on a SSD sucks because SSDs lack write-in-place.
However sparse files on a SSD can be even worse because libtorrent (qBitTorrent and Deluge) has horrific levels of file fragmentation due to tiny 16 KB writes.
It should be writing whole pieces in 1 go, so giant files at least are typically only fragmented in 1-4 MB pieces.

@Seeker2 commented on GitHub (Jul 21, 2017): Zero-filling on pre-allocate on a SSD sucks because SSDs lack write-in-place. However sparse files on a SSD can be even worse because libtorrent (qBitTorrent and Deluge) has horrific levels of file fragmentation due to tiny 16 KB writes. It should be writing whole pieces in 1 go, so giant files at least are typically only fragmented in 1-4 MB pieces.

deekerman commented

2026-02-21 18:03:23 -05:00

Author

Owner

@DanielSmedegaardBuus commented on GitHub (Jan 13, 2020):

I may be misunderstanding something here, or I may be conflating this, so if this is the case, I apologise.

As far as I understand the referenced libtorrent issue, it ends up with explaining that pre-allocation won't work without administrative privileges on Windows, so if it cannot do it on the FS level, it'll then revert to doing zero-filling.

But qbt does neither? If I could get either of the libtorrent pre-allocation strategies to work in qbt, I'd be one happy camper, but unfortunately, qbt won't pre-allocate anything, with or without administrative privileges (Windows 10 LTSC), and there's no fall-back to zero-filling (which would do just fine for me) either, so no matter the setting or privileges, there's no pre-allocation going on.

This seems like it might be an issue with qbt then? That it simply fails to activate either strategy in libtorrent when you toggle the setting? Or is my box just getting a special dose of cosmic rays? :D

@DanielSmedegaardBuus commented on GitHub (Jan 13, 2020): I may be misunderstanding something here, or I may be conflating this, so if this is the case, I apologise. As far as I understand the referenced libtorrent issue, it ends up with explaining that pre-allocation won't work without administrative privileges on Windows, so if it cannot do it on the FS level, it'll then revert to doing zero-filling. But qbt does neither? If I could get either of the libtorrent pre-allocation strategies to work in qbt, I'd be one happy camper, but unfortunately, qbt won't pre-allocate anything, with or without administrative privileges (Windows 10 LTSC), and there's no fall-back to zero-filling (which would do just fine for me) either, so no matter the setting or privileges, there's no pre-allocation going on. This seems like it might be an issue with qbt then? That it simply fails to activate either strategy in libtorrent when you toggle the setting? Or is my box just getting a special dose of cosmic rays? :D

deekerman commented

2026-02-21 18:03:23 -05:00

Author

Owner

@DanielSmedegaardBuus commented on GitHub (Jan 13, 2020):

Okay, I figured out that the bug is actually somewhere else in qBittorrent. Changing the setting has zero effect on torrents that have already been loaded, but not yet started. It will only have an effect on torrents that are added after you change the setting.

Even with that, the behaviour is still broken, but I'm unsure if this is qbt's fault or libtorrent's. Either way, with pre-allocation actually functional, space is indeed reserved for torrents added while the setting is on, as soon as files are written to while downloading, but it has seemingly no effect on fragmentation, rendering the setting kinda moot.

For instance, I have an 87 GB file currently downloading, with pre-allocation on, and all space having been pre-allocated as the torrent started. However, that pre-allocated file currently consists of over seven thousand file fragments, at 31.2% completion.

The libtorrent docs mention

storage_mode_allocate
All pieces will be written to their final position, all files will be allocated in full when the torrent is first started. This is done with fallocate() and similar calls. This mode minimizes fragmentation.

Is this not the mode used when enabling pre-allocation? Is there anything else that needs configuration besides pre-allocation in order to prevent fragmentation?

@DanielSmedegaardBuus commented on GitHub (Jan 13, 2020): Okay, I figured out that the bug is actually somewhere else in qBittorrent. Changing the setting has zero effect on torrents that have already been loaded, but not yet started. It will only have an effect on torrents that are added after you change the setting. Even with that, the behaviour is still broken, but I'm unsure if this is qbt's fault or libtorrent's. Either way, with pre-allocation actually functional, space is indeed reserved for torrents added while the setting is on, as soon as files are written to while downloading, but it has seemingly no effect on fragmentation, rendering the setting kinda moot. For instance, I have an 87 GB file currently downloading, with pre-allocation on, and all space having been pre-allocated as the torrent started. However, that pre-allocated file currently consists of over seven thousand file fragments, at 31.2% completion. The libtorrent docs mention > storage_mode_allocate > All pieces will be written to their final position, all files will be allocated in full when the torrent is first started. This is done with fallocate() and similar calls. This mode minimizes fragmentation. Is this not the mode used when enabling pre-allocation? Is there anything else that needs configuration besides pre-allocation in order to prevent fragmentation?

deekerman referenced this issue

2026-02-21 20:41:33 -05:00

[Tool] Batch close old issues #10312