ferdnyc
commented
2 years ago I have allocation turned off.
You have complete pre-allocations turned off — if you turned them on, then BiglyBT would create a full-size, zeroed file for each download target. Because that's disabled, it only allocates the space it needs.
Pre-allocations aren't all allocations. Allocations can't be completely turned off, they're part of the file-creation process.
I have sparse files mode turned on, and I don't like a bunch of incomplete files on my hard drive when they actually have no data.
But sparse mode has nothing to do with that. All sparse mode means is that you don't have to pad a file out to full-size, when it contains mostly empty space. That comes in handy when only the last piece of a file needs to be downloaded. Without sparseness, a 50MB file with only 256K of data right at the end would have a size of 50MB, and the first 40.74MB 49.74MB would be filled with 0s. Sparseness allows that same file to have a size of 256K. But it has nothing to do with the existence of the file itself.
When a torrent is started, enabled files are opened for writing. ("Enabled files" includes border files which may themselves be set "do not download", but have their first/last piece enabled because they share that piece with an enabled file.) That creates, if nothing else, a 0-byte file on disk for each enabled output. That's just how it works. The data's got to go somewhere after it's received. Download speeds would plummet, if each time a piece is received there had to be a check for an existing file, a creation if it didn't exist, and a space allocation for the piece. That's a lot of "stuff" to do in the middle of receiving data. (Not to mention, there's way more potential for collisions when two or more pieces of the same file are received at virtually the same moment.)
That "Limit active major disk operations..." checkbox is probably the only reason you can even see the allocation phase on startup. Normally it goes by too quick to even notice, since all it has to do is open a bunch of files and (possibly) seek to the start of the active data region.
If those same torrents were just active, a lot of that can probably be done from the disk cache. But if the allocations have to wait in line with piece re-checks, that'll cause delays. (And possibly cache misses, as the data for previously-opened files is edged out by re-checked pieces being read in.)
Also depends what type of media you're using. With an SSD, there's no reason at all to make disk operations queue up and take turns. With spinning rust, there's a little more room to debate the benefits tradeoff.
as-muncher
realkot
parg
Java 1.8.0_202 (64 bit) Oracle Corporation c:\program files\biglybt\jre
SWT v4942r22, win32, zoom=100, dpi=120 Windows 10 v10.0, amd64 (64 bit) B2.9.0.1_B15/4 az3
When I'm shutting the software down, BiglyBT puts all the torrents into a stopped state, but when starting them up, allocates, then checks, although it's a quick check usually, then queues them. I have allocation turned off. I have sparse files mode turned on, and I don't like a bunch of incomplete files on my hard drive when they actually have no data. This happens when my computer is in airplane mode, so it's not that data is being downloaded and that's why I'm seeing all these allocated files with the .!qB extension.
