pre-allocation set to 2 is per torrent or per file?

[rezad1393]

hi
this may be a stupid question , but when I set pre-allocation to 2 ( to see if I can reduce fragmentation because level 1 didn't help) and add a big torrent with huge files transmission doesn't creates files in the incomplete folder until some data has been downloaded for a file.
so I get some files shown in incomplete folder but they appear one by one after it seems that transmission has downloaded at least some bytes of data for them.

it this the intended behavior?
so if I add a torrent but not run it no files is created, and this is correct way?
can I be sure that the files is allocated fully on disk?
how can I test that and see the difference with pre-allocation set to 1?
I mean with a command.

my os is linux-64 and my FS is ext4 and transmission the latest version (3 i think).

also on a filesystem like ext4 the free space reported differs between two options?
and when I allocate full (option set to 2) the good thing about ext4 is that it sets aside the file space for it and reports it full but doesn't actually fill it with anything like zeros right?

where would I see the difference with allocation set to full on ext4 between a file allocation at the star and when file is almost fully downloaded?
in df command? du command?

[ckerr]

but when I set pre-allocation to 2 ( to see if I can reduce fragmentation because level 1 didn't help) and add a big torrent with huge files transmission doesn't creates files in the incomplete folder until some data has been downloaded for a file. so I get some files shown in incomplete folder but they appear one by one after it seems that transmission has downloaded at least some bytes of data for them.

it this the intended behavior?

Yes. Preallocation happens per-file just before writing the first downloaded byte into that file.

so if I add a torrent but not run it no files is created, and this is correct way?

Yes.

can I be sure that the files is allocated fully on disk?

I don't understand the question? There's not a way in Transmission's GUI. You would inspect the file itself the same way you would any other file on your OS.

how can I test that and see the difference with pre-allocation set to 1? I mean with a command. where would I see the difference with allocation set to full on ext4 between a file allocation at the star and when file is almost fully downloaded?

On Linux + ext4 both sparse and full allocation should give the same results. On POSIX systems, both codepaths try fallocate64() first. Transmission prefers that preallocation on POSIX machines because it's fast and does the job. So unless fallocate64() fails on your system (not sure why that would happen on an ext4 system?) then sparse & full will give the same behavior.

Really, 'sparse' and 'full' are basically shorthand for "fully allocate the file if you can do it quickly" and "fully allocate the file even if we're on a dumb filesystem that doesn't support preallocation. In fact, write an empty buffer to disk inside a loop if you have to."

[rezad1393]

If you know of a better approach than fallocate64() to prevent fragmentation, I'm all ears

I meant that I am not a programmer.
so I asked for clarification and not insult.

[ckerr]

I don't know of any surefire way to prevent any file fragmentation on the system. Each filesystem makes its own crazy decisions based on whatever internal heuristics it uses. Generally fallocate64() will cause a minimum of fragmentation but there are no guarantees.

There is a secondary approach that is ZFS-specific, so running on a ZFS filesystem may yield different results.

[rezad1393]

hmmm.
now you got me curious.
I want to test btrfs (or zfs) but I am a noob with them. I use the default ext4 mostly but been trying to see data checksum ability of those two filesystem to check against bitrot.

can you point me to that "a secondary approach that is ZFS-specific" ? a article would be great.

btw do you personally use btrfs or zfs, and can you recommend one for a noob like me?

[ckerr]

I'm very sorry, I meant XFS. Huge difference. No, you don't want to use XFS. My bad. If anyone's curious, this is what I was referring to.

I have used btrfs / zfs / ext4 and don't have strong opinions about one over the other for day-to-day torrenting use. If whatever you're using now is working for you, I'd say keep using it :)

[rezad1393]

I am trying to use btrfs on a local lan server (armv7) but if I am not wrong it make my hdd drive slow with too much fragmentation , specially because of torrenting and freenet datastore.
if zfs becomes slow like that maybe I should forgo both and go back to ext4.