aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Author Topic: Benefit of Big "min disk space"  (Read 4050 times)

dealcorn

  • Approved Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 16
Benefit of Big "min disk space"
« on: April 03, 2012, 08:06:16 AM »

I want to move my aMule/Temp (and a separate /root partition) to a msata drive that that consumes less than 0.2 watts but does not provide much space.  When a download completes I will spin up a 2.5" drive as a destination for the completed download so my focus is on solely on .aMule/Temp.  I run a non sparse file system and I do not expect that to change when I switch disks.

Currently I have set file preferences to check for free disk space with a 1 GB "min disk space".  I do not preallocate disk space for new files but I do start next paused file when a download completes.  I observe that when I add a download in paused mode it does not preallocate the requisite disk space.  When a download becomes active, disk space is allocated for the full download size. I assume, but have not verified, that if I only have 1.5 GB of free disk space aMule will refuse to start a 2.0 GB download because actual disk space is inadequate notwithstanding the 1 GB min disk space parameter.

My understanding is that aMule can run with "min disk space" space of a bit less than 10 MB.   It seems that in a non sparse environment, active downloads have space to complete and aMule presumably will not start a paused file if it is unable to allocate the requisite space to complete? 

What is the benefit of setting a "min disk space" parameter greater than 10 MB?  It sounds like aMule will keep me safe with a 10 MB "min disk space".
Logged

Stu Redman

  • Administrator
  • Hero Member
  • *****
  • Karma: 214
  • Offline Offline
  • Posts: 3739
  • Engines screaming
Re: Benefit of Big "min disk space"
« Reply #1 on: April 03, 2012, 08:51:44 PM »

Well, I wrote a perfectly working temp file system that didn't fill all the space once a chunk near the end of the file gets downloaded (and that didn't fragment the disc as bad as sparse files do) some years ago. (Actually two of them now that I think about it.) Unfortunately the patch was not accepted.
Logged
The image of mother goddess, lying dormant in the eyes of the dead, the sheaf of the corn is broken, end the harvest, throw the dead on the pyre -- Iron Maiden, Isle of Avalon

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Benefit of Big "min disk space"
« Reply #2 on: April 03, 2012, 09:26:37 PM »

My understanding is that aMule can run with "min disk space" space of a bit less than 10 MB.   It seems that in a non sparse environment, active downloads have space to complete and aMule presumably will not start a paused file if it is unable to allocate the requisite space to complete?  
That's not true.

First of all, in a non-sparse environment the allocated file size is always equal to to the address of the last written byte. That is, if you download a 2.0 GB file, and aMule writes data at 1.5 GB, the system will first allocate the (not yet used) first 1.5 GB, then write the actual data at 1.5 GB. If you write a single byte at the end of the file, the whole file will be allocated, regardless of the size and the amount of space it needs (unless the disk gets full meanwhile).
Since aMule cannot predict when and what will happen on a write, it will happily start downloading a 2.0 GB file even if only 1.0 GB disk space is free.

Considering the above, your choices are:
1) Use a sparse file system. Then aMule will always stop when the free disk space drops under the preset minimum, and will never use up all space on the drive.
2) Preallocate space for new downloads. This ensures that no more disk space will be used while downloading and started downloads can finish. The drawback is, that you must manually ensure that there's enough space on the drive before you select a new file to download.
3) With your settings, you have two choices:
  (a) Set min disk space to a low value. That means, aMule will sooner or later fill the whole drive, and you'll get "No space left on device" errors.
  (b) Set min disk space to a high value (bigger than your biggest file you want to download). In this case, aMule can't fill the disk, but will leave a lot of space unused.
  (c) If you want to make sure aMule can work unattended, you should set min disk space to a low value (so then almost all of the disk space can be used for downloading), and, if you download n files at once, ensure that there's enough space on the drive for the n biggest files to complete at once, in addition to the min disk space.

Let's see an example: say, I use a 4.0 GB SSD for downloading, then I move completed files to another HDD. I download CD images approximately 700 MB each. Then I'd set min disk space to the lowest, and not let more than 5 downloads to run at any time, because that will use at most ~3.5 GB, not filling the disk. If I'd let a 6th download start, it might (but not necessarily will) cause a disk full error.

What is the benefit of setting a "min disk space" parameter greater than 10 MB?  It sounds like aMule will keep me safe with a 10 MB "min disk space".
If you run aMule on a system where the temporary directory is on the root device, or on the device containing /home in a multi-user environment, it is highly advisable that you don't eat up all disk space from the system (or from other users). System administrators can get angry...
Logged
concordia cum veritate

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Benefit of Big "min disk space"
« Reply #3 on: April 03, 2012, 09:27:11 PM »

Unfortunately the patch was not accepted.
That still might change in the future.
Logged
concordia cum veritate

Stu Redman

  • Administrator
  • Hero Member
  • *****
  • Karma: 214
  • Offline Offline
  • Posts: 3739
  • Engines screaming
Re: Benefit of Big "min disk space"
« Reply #4 on: April 03, 2012, 11:00:31 PM »

You mean you have been considering and considering it for 3 1/4 years?  :P
Logged
The image of mother goddess, lying dormant in the eyes of the dead, the sheaf of the corn is broken, end the harvest, throw the dead on the pyre -- Iron Maiden, Isle of Avalon

dealcorn

  • Approved Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 16
Mid Course Correction
« Reply #5 on: April 04, 2012, 03:19:30 AM »

After double checking my Temp directory I agree that I got it wrong and the space allocated to active downloads is based on last byte written.  Now I understand how aMule could lock the system if you get it wrong.  Even after the Thailand flooding, disk space is cheap enough that the prudent thing to do is have abundant free disk space so these concerns are not relevant.

My other boo boo is that aMule appears not to distinguish between active vs paused downloads in this context.  Disk space is allocated based on last byte written or full preallocation depending on your preallocate parameter. 

The way GonoszTopi laid out the alternatives, a sparse file system is starting to sound good for a ssd (and it was option #1).  My spin on the benefit is that for a given level of download activity, a sparse file system requires less hard disk space because you do not allocate for empty space. This is not where I expected to wind up and I am glad I asked.  Is there a suggested "min disk space" parameter for sparse file systems?
Logged

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Benefit of Big "min disk space"
« Reply #6 on: April 04, 2012, 08:46:18 PM »

Is there a suggested "min disk space" parameter for sparse file systems?
If you have a dedicated partition/drive/device for your Temp folder, you can leave it as low as possible. Otherwise I'd suggest something like 1 GB (10 MB is way too little for a running OS).

You mean you have been considering and considering it for 3 1/4 years?  :P
No, but I may reconsider it for 3.0.0 ;)
Logged
concordia cum veritate