You are not logged in.

#1 2017-03-07 15:20:20

nannerpussy
Member
Registered: 2017-02-15
Posts: 96

[SOLVED] Built-in limitation on /tmp folder?

I'm putting this in the newbie section because it's possible this is a feature or system safety measure that is independent of Arch or maybe was a setup option I missed somewhere early on, but right now I have Arch installed on my only main system drive, setup with three basic partitions. EFI boot, root, swap. I don't run any other distros right now, but I did section off these partitions into a 600GB chunk, with about 400GB unallocated for later use or if I decide I don't hate LVM2. Basically, a pretty standard install with no partition shenanigans for /home or anything. However, after streaming torrents with Popcorn Time I started getting low disk space warnings. This isn't unexpected with how large these movies are in 1080p and usually after I close out or empty my Popcorn Time cache, the issue goes away. Not even an issue, really, that is working as intended I guess.

But just in case, I tracked down what I could about it being related to PopcornTime and how it handles the cache, but just now pacman completely quit on me and I was getting bash-completion errors when I tried to Tab a command. Like it is literally, completely out of room to write to my HDD. Using Nemo/Cinnamon I can check just /tmp and it is telling me I only have 4.6GB of free space left, which is incorrect. It's closer to 340GB free space if I check my root directory. I ran Bleachbit very selectively and did a disc use probe, but nothing stands out and I can't find a bottleneck or option to allow pacman/yaourt/tmp to use all the space it needs. Why would /tmp think I'm low on disk space and why would pacman completely break itself over a non-existent limit? Clearly I screwed something up here (I hope so anyway), but short of re-partitioning and devoting an obscene amount of disc to just my /tmp directory, I'm a bit confused about why this is happening to begin with.

I don't know what's relevant here as far as doing an inxi query, but I have no special partitioning or schemes or filesystems in use. Just a basic two-partition-plus-swap install of Arch, everyone being lumped into the single root partition.

Last edited by nannerpussy (2017-03-07 15:40:34)

Offline

#2 2017-03-07 15:31:09

Slithery
Administrator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 5,776

Re: [SOLVED] Built-in limitation on /tmp folder?

In a standard Arch installation /tmp is a temporary filesystem located in RAM, and limited to half the size of the installed memory.

https://wiki.archlinux.org/index.php/Tmpfs


No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Offline

#3 2017-03-07 15:31:11

ayekat
Member
Registered: 2011-01-17
Posts: 1,590

Re: [SOLVED] Built-in limitation on /tmp folder?

mount | grep /tmp

Also, pacman should not be using /tmp, as far as I know.

--edit--
ah - ninja'd by 2 seconds >.<

Last edited by ayekat (2017-03-07 15:31:41)


pkgshackscfgblag

Offline

#4 2017-03-07 15:31:15

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,591

Re: [SOLVED] Built-in limitation on /tmp folder?

By default, /tmp is mounted in tmpfs in RAM; default size is half your RAM.

Offline

#5 2017-03-07 15:35:46

nannerpussy
Member
Registered: 2017-02-15
Posts: 96

Re: [SOLVED] Built-in limitation on /tmp folder?

Well then I did post this in the right spot lol..

Would the best way to go about fixing this be to partition off a big section and just mount tmp there? I didn't setup LVM for this install and I'm regretting that now, but I did leave the partitions in the right order to expand..

Offline

#6 2017-03-07 15:37:44

Slithery
Administrator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 5,776

Re: [SOLVED] Built-in limitation on /tmp folder?

Read the link I posted, it explains how to disable the tmpfs mount.


No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Offline

#7 2017-03-07 15:38:22

progandy
Member
Registered: 2012-05-17
Posts: 5,201

Re: [SOLVED] Built-in limitation on /tmp folder?

For most tasks the size of /tmp is sufficient and tmpfs is faster than caching temporary data to a disk. pacman runs fine with that, but you might run into problems if you are building large packages from source. In that case either change your build directory or unmount the /tmp filesystem and write it to disk as the wiki article you have been given describes.

If yaourt has been written correctly, it should have options to change the build and temporary directories with environment variables or commandline switches.

Last edited by progandy (2017-03-07 15:40:53)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#8 2017-03-07 15:40:11

nannerpussy
Member
Registered: 2017-02-15
Posts: 96

Re: [SOLVED] Built-in limitation on /tmp folder?

slithery wrote:

Read the link I posted, it explains how to disable the tmpfs mount.

Awesome, thanks for the speedy replies everyone.

Offline

#9 2017-03-07 15:55:44

nannerpussy
Member
Registered: 2017-02-15
Posts: 96

Re: [SOLVED] Built-in limitation on /tmp folder?

progandy wrote:

For most tasks the size of /tmp is sufficient and tmpfs is faster than caching temporary data to a disk. pacman runs fine with that, but you might run into problems if you are building large packages from source. In that case either change your build directory or unmount the /tmp filesystem and write it to disk as the wiki article you have been given describes.

If yaourt has been written correctly, it should have options to change the build and temporary directories with environment variables or commandline switches.

yaourt does indeed have the switches, or did when I last looked, but removing the tmpfs limitation altogether is exactly what I was looking for. I compile lots of huge crap like mesa-test-git and stream and do other tmp-stretching things often enough that a total removal of a cap is perfect.

Offline

Board footer

Powered by FluxBB