Mageia forum

I'm trying to install an update from Android Studio, but this results in error: the file is downloaded, but when it is unzip by Android Studio I get an error message as below:

[img]file:///home/tdms/Imagens/Captura%20de%20tela%20de%202016-07-05%2001%3A27%3A49.png[/img]

The problem is: I have no enough space in my computer! The file is only 444Mb, and I have more than 100 Gb available in home partition.

But when I check it out in terminal by using

Code: Select all

df -l

, I get this:

Code: Select all

[tdms@localhost ~]$ df -lh
Sist. Arq.      Tam. Usado Disp. Uso% Montado em
devtmpfs        1,8G     0  1,8G   0% /dev
tmpfs           1,8G  2,4M  1,8G   1% /dev/shm
tmpfs           1,8G  1,1M  1,8G   1% /run
/dev/sda5        50G  7,4G   40G  16% /
tmpfs           1,8G     0  1,8G   0% /sys/fs/cgroup
tmpfs           1,8G  1,8G  2,1M 100% /tmp
/dev/sda1       100M   25M   76M  25% /media/win_c
/dev/sda7       148G   13G  136G   9% /home
/dev/sda2       154G  135G   20G  88% /media/win_d
tmpfs           365M   24K  365M   1% /run/user/1000
tmpfs           365M   12K  365M   1% /run/user/1002


So, the problem is the /tmp, but I didn't created any partition /tmp and the available 1,8Gb is to little... Is there anything I can do to solve this, maybe expanding this partition?

And, why I have this partition, with this fixed value and all my downloads stay in it instead of home partition?

Thanks in Advance!

Hello,

The /tmpfs partition is created in your RAM, you need more RAM, how much is it ? Do you have a swap ? if not, you should.

You may or may not need more RAM, but what you do need to do is move /tmp out of RAM.

This is a peculiar default of Mageia. It is, IMHO, not a good default...for exactly the reason you are encountering.

I am very short of time at the moment (I have to catch a plane) or I would look it up for you, but someplace on this board are posts telling you how to move /tmp to a hard drive. Search and you shall find.

It's java program you need to tell java to use your home folder to store temp files so you don't need to move whole /tmp out from ram.
http://stackoverflow.com/questions/3805 ... ndroid-sdk

Lebarhon wrote:you need more RAM, how much is it ? Do you have a swap ? if not, you should.

tmpfs by default is half the size of the RAM, ignoring swap from what I remember. So usable RAM should be ~3.6GB

And in this particular case jiml8 is very spot-on, /tmp should be changed to a separate partition as 1.8GB is very limiting IMHO.
More RAM would only be a workaround, and it also costs money.

Lebarhon wrote:Hello,

The /tmpfs partition is created in your RAM, you need more RAM, how much is it ? Do you have a swap ? if not, you should.

So, I need more RAM... I have 4GB of swap

jiml8 wrote:You may or may not need more RAM, but what you do need to do is move /tmp out of RAM.

This is a peculiar default of Mageia. It is, IMHO, not a good default...for exactly the reason you are encountering.

I am very short of time at the moment (I have to catch a plane) or I would look it up for you, but someplace on this board are posts telling you how to move /tmp to a hard drive. Search and you shall find.

No worries man, and have a good trip on plane!

Searching on internet, I find results to increase this partition on RAM, something like that:

Code: Select all

# mount -o remount,size=4G,noatime /tmp

I don't try the above, because the I had 4GB at that moment... No more RAM for nothing...

doktor5000 wrote:

Lebarhon wrote:you need more RAM, how much is it ? Do you have a swap ? if not, you should.

tmpfs by default is half the size of the RAM, ignoring swap from what I remember. So usable RAM should be ~3.6GB

And in this particular case jiml8 is very spot-on, /tmp should be changed to a separate partition as 1.8GB is very limiting IMHO.
More RAM would only be a workaround, and it also costs money.

I found a better solution with my savings: I just upgraded to 8GB of RAM. Now the /tmpfs has 3,38G of available space, I just updated my Android Studio

In fact I had 4GB of RAM, with a 64bits system, so I found strange the system recognize only 3,6GB...

Anyway, problem solved, and once more Thank all of you who helped me a little more!

tdmsoares wrote:In fact I had 4GB of RAM, with a 64bits system, so I found strange the system recognize only 3,6GB...

Happens often when graphics card also uses some RAM as shared memory, especially with cpu-integrated graphics,
and many normal dedicated graphics cards can also use some system RAM. Also due to some PCI(e) implementations grabbing some of the system RAM.

tdmsoares wrote:
I found a better solution with my savings: I just upgraded to 8GB of RAM. Now the /tmpfs has 3,38G of available space, I just updated my Android Studio

In fact I had 4GB of RAM, with a 64bits system, so I found strange the system recognize only 3,6GB...

Anyway, problem solved, and once more Thank all of you who helped me a little more!

Your problem is not solved, just mitigated.

I first became aware that Mageia was putting /tmp in RAM when I ran out of space in my /tmp folder on my 32 GB system. Yes, /tmp filled 16GB of RAM, then my video transcode failed. That is when I put /tmp back on a hard drive, where it belongs. I did not put it in a partition, but in a file located on a big partition.

I actually have my system currently set up with 32 GB RAM as well as 35 GB of swap, and at this time all RAM is full with 5 GB of swap in use. I really don't need (or want) /tmp to be sucking up my RAM.

tdmsoares wrote:
In fact I had 4GB of RAM, with a 64bits system, so I found strange the system recognize only 3,6GB...


Happens often when graphics card also uses some RAM as shared memory, especially with cpu-integrated graphics,
and many normal dedicated graphics cards can also use some system RAM. Also due to some PCI(e) implementations grabbing some of the system RAM.

In my case it's a cpu-integrated graphics... But I didn't realize that dedicated graphic cards could take some RAM, they have their own memory in their cards...

Your problem is not solved, just mitigated.

I first became aware that Mageia was putting /tmp in RAM when I ran out of space in my /tmp folder on my 32 GB system. Yes, /tmp filled 16GB of RAM, then my video transcode failed. That is when I put /tmp back on a hard drive, where it belongs. I did not put it in a partition, but in a file located on a big partition.

Having half of available RAM used by a partition is not a good thing, and it's surprising you had a problem having 32 GB ...
But searching in google for this, I found topics to move the /tmp to RAM and not from RAM to hard disk!

In my case I have 40GB in main partition and others 140 GB in /home. So should I mount the /tmp in main partition or just move this dir to root?

People put /tmp in RAM because RAM is a lot faster, and they think their system will run faster if /tmp is not written to disk. Also, as a security issue, /tmp in RAM is more secure; the contents do not survive a power off or reboot. Usually, in day to day use, /tmp does not get that big. Mine presently is 11 Meg.

However, RAM is a relatively scarce and expensive resource, while hard drive space (and even SSD space) is much cheaper and far more plentiful. Given disk caching, the I/O times for /tmp are seldom an issue. Placing /tmp on an encrypted partition makes it fully secure.

And sometimes, depending on what you are doing, you will find /tmp getting filled up, to the point where your RAM-based /tmp won't be big enough no matter how much RAM you have. In my case, I got bitten while doing a large video transcode; some of the files were being cached in /tmp and I did not realize the problem.

In my not at all humble opinion, the advantages of /tmp in RAM are vastly outweighed by the potential disadvantages; I would recommend against doing it. You may have enough RAM, but you never have too much RAM...and placing /tmp in RAM wastes it.

Similarly, you will find many people on the web recommending that you disable swap (as a "performance enhancement") on a big-memory Linux system (say...above 8 GB) but it has been my experience that Linux wants that swap, regardless of how much RAM you have. Disabling swap will result in an intermittently unstable system, with symptoms you will have the devil's own time sorting out. As I say, my 32GB system has 35GB of swap, and presently 5GB is in use.

There is nothing at all wrong with experimenting, and tweaking, and trying different things. I have done that for many years myself, and I do things today the way I do them based upon what I have learned over time from all that tweaking. And figuring out that I really needed to greatly increase the swap available for my system took me a looonggg time...particularly in the face of all the googling I did that told me that a big-memory system doesn't need swap.

The moral of the story is: try things. Listen to what others say also, but use your common sense, and pay attention to your own experiences. In the current situation, you have been bitten by an out of resources condition due to /tmp in RAM. Why would you think that merely doubling RAM would prevent you from having the problem again?

For myself, /tmp is a directory on a 4 TB partition on a decently fast hard drive. I symlink to it from the root of the file system. It works fine that way, and I have to fill that entire drive to run out of /tmp.

Just adding my 2 cents here.
By normal operations, when we reboot, /tmpfs is cleared out.
After reboot, check again with "df -h", if it is so.

If not, check if your /etc/fstab has any entry for this /tmpfs. Comment out and try again (reboot).

jiml8 wrote:People put /tmp in RAM because RAM is a lot faster, and they think their system will run faster if /tmp is not written to disk. Also, as a security issue, /tmp in RAM is more secure; the contents do not survive a power off or reboot. Usually, in day to day use, /tmp does not get that big. Mine presently is 11 Meg.

However, RAM is a relatively scarce and expensive resource, while hard drive space (and even SSD space) is much cheaper and far more plentiful. Given disk caching, the I/O times for /tmp are seldom an issue. Placing /tmp on an encrypted partition makes it fully secure.

And sometimes, depending on what you are doing, you will find /tmp getting filled up, to the point where your RAM-based /tmp won't be big enough no matter how much RAM you have. In my case, I got bitten while doing a large video transcode; some of the files were being cached in /tmp and I did not realize the problem.

In my not at all humble opinion, the advantages of /tmp in RAM are vastly outweighed by the potential disadvantages; I would recommend against doing it. You may have enough RAM, but you never have too much RAM...and placing /tmp in RAM wastes it.

Similarly, you will find many people on the web recommending that you disable swap (as a "performance enhancement") on a big-memory Linux system (say...above 8 GB) but it has been my experience that Linux wants that swap, regardless of how much RAM you have. Disabling swap will result in an intermittently unstable system, with symptoms you will have the devil's own time sorting out. As I say, my 32GB system has 35GB of swap, and presently 5GB is in use.

There is nothing at all wrong with experimenting, and tweaking, and trying different things. I have done that for many years myself, and I do things today the way I do them based upon what I have learned over time from all that tweaking. And figuring out that I really needed to greatly increase the swap available for my system took me a looonggg time...particularly in the face of all the googling I did that told me that a big-memory system doesn't need swap.

The moral of the story is: try things. Listen to what others say also, but use your common sense, and pay attention to your own experiences. In the current situation, you have been bitten by an out of resources condition due to /tmp in RAM. Why would you think that merely doubling RAM would prevent you from having the problem again?

For myself, /tmp is a directory on a 4 TB partition on a decently fast hard drive. I symlink to it from the root of the file system. It works fine that way, and I have to fill that entire drive to run out of /tmp.

I agreed with you: having the expensive RAM bitten by the /tmp is a thing to consider, however as you said there are security problems when you point this folder in hard disk... So we have a dilemma: I one hand, a safer system and the other hand a system with a better performance.
As I understood, you just created a symbolic link in /tmp to the Hard Disk, right? But what if I create a partition in Hard disk to /tmp, I would solve this dilemma? (Having a better performance with a more safe system)

gohlip wrote:Just adding my 2 cents here.
By normal operations, when we reboot, /tmpfs is cleared out.
After reboot, check again with "df -h", if it is so.

If not, check if your /etc/fstab has any entry for this /tmpfs. Comment out and try again (reboot).

Yeah, even not rebooting I saw the /tmpfs clearing the content. But the problem I was facing with a 4GB RAM system was having only 1,8GB of space to install a update over this size... Even I rebooting the system, I ended up having only 1,8GB: not enough in that case...