Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Recently I have come to believe a number of unusual occurrences that have happened while running a Parted Magic Live CD, are the result of running out of space on the RAM based filesystem, namely:

  • Folder contents disappearing, only to reappear later
  • Mount-gtk not showing single mounted drive/not allowing unmount (While bash mount commands function normally)
  • Firefox freezing, then seemingly freezing the GUI.
  • My Firefox session recovering as if the browser crashes at each clean close
  • Loosing last x minutes of Firefox session history
  • Sound/clipboard redirection intermittently not working in rdesktop
  • Conky crashing periodically

...Not despite the SpaceFM warning of no space to store state data AND some of these problems disappearing only after moving some files off the filesystem.

Problem being, I am not sure how to (at least) keep an eye on the "space" left of the filesystem (Note: There is no entry for the / partition in the output of df, fdisk -l or mount), let alone (assuming I am right that the filesystem space not being relative to the system memory, that I had been monitoring with conky) how to go about increasing the sizing ?at boot time?

Help?

P.S Thought it most appropriate to tag this question with , (or ... Not sure how to identify which one is in use) and like tags, but alas there doesn't appear to be any of them. If the community doesn't want to create one/all, please feel free to suggest other tags that others feel are appropriate.

share|improve this question
    
Are you using Parted as your regular distribution for day to day work? –  terdon Sep 15 '13 at 4:37
    
No, just tend to use it often enough that some regular work gets done on it at the same time, and some tasks (which involve temporarily logging that I don't want to dump onto non-volatile storage) require sometimes days of uptime. I realise the downsides of running a Live CD for day-to-day work, if this is where you were going with your question. –  user66001 Sep 15 '13 at 5:02
    
Well, yes, I mean it's not even a Live CD. Well, it is technically, but it's only meant to be used for partitioning and disk management, not day to day stuff. It's bound to have problems like this, the only answer you're likely to get is don't use Parted Magic as an OS. If you need a live CD go for a proper one. –  terdon Sep 15 '13 at 5:06
    
I am not sure how that is an answer to this question, and not (something like) "Should I use Parted Magic for everyday work?". I could remove all mention of the distro I am using, if people think this will get the fundamental "How to tell space left on a ?RAM/TMP FS? that doesn't appear in the output of df, fdisk -l or mount?" question answered. –  user66001 Sep 15 '13 at 5:10
1  
I am still unsure why everyone seems fixated on what they think I am using this OS for... I have already stated that I am not using it for my day-do-day work (This includes not using it for general browsing of the internet/listening to music!), not even 1% of my day-to-day work in fact. Again, I have a log of rescue operations that are running, that is being stored on the volatile storage (for reasons of it being unrelated to the question of Space left on Linux RAM/TMP,FS, will not be detailing here), and probably the reason for this question. Please stop commenting along these lines –  user66001 Sep 15 '13 at 20:30

4 Answers 4

By default, a tmpfs ramdisk will be set up to use a maximum of half of the available RAM in the system (note that a standard, non-PAE, 32-bit kernel can address a maximum of 4GB less any address space used by devices like VGA cards).

I've just booted Parted Magic 2013 08 01 in a virtual machine, giving it 4GB RAM. The rootfs has a total of 2GB, with about 444KB used, so PM is using the defaults for tmpfs. If i reboot the VM with only 1GB RAM, the root tmpfs has only 504MB available - the kernel uses some, so that's slighly less than half total RAM.

It also mounts /tmp and /run as tmpfs of the same size. Note that these filesystems are not additional space, they use the same pool of RAM as the rootfs and any running programs (i.e. slightly less than 1GB on a system with 1GB RAM).

(BTW, df wouldn't even run until i deleted /etc/mtab and replaced it with a symlink to /proc/mounts).

The important thing to remember is that tmpfs and any programs running share the same system memory - so if you fill up the tmpfs, it will reduce the amount of RAM available for running programs, and if you run programs that use lots of RAM, it will reduce the amount of RAM available for tmpfs.

You seem to be doing both. You're filling up the disk with your log files, AND you're running firefox, X, and rdesktop - all of which tend to use large amounts of RAM. Unix systems don't react well when the rootfs gets full, and when RAM starts getting tight the Linux kernel's out-of-memory (OOM) task will start randomly killing processes to free up some RAM.

Either of these factors alone will cause weird, unpredictable problems. Both together just make the problems inevitable.

As others have suggested, I strongly recommend that you don't use a Live CD (Parted Magic or any other) in this way. They're not designed for it, and what you are doing is pretty much guaranteed to cause problems. In short, Don't Do That, Then!.

Instead, either re-partition your hard disk and install a small distro onto it, run a linux distro in a VM, or find a distro that installs and runs off a USB stick without using tmpfs for /root - i.e. uses the USB stick as its root filesystem (this would be a lot slower than running from a tmpfs. and no, I don't know of any that work like that). or use a USB hard disk rather than a USB flash disk.

BTW, How much RAM do you have in your system and what version of Parted Magic are you running?

share|improve this answer
    
First off THANK-YOU for answering the question, and for the time detailing all that info (Wish I could upvote this more than once). As to your questions first - 2.93Gb RAM & Parted Magic 2012_09_12. So - Do you have any good references for tmpfs info (Particularly info to become familiar with it's settings)? As for your comment about df, having just learnt about the /proc/mounts pseudo file, I have found far more mount points listed in this, than what mount outputs (Including / /dev /tmp, etc)... Any idea why? –  user66001 Sep 16 '13 at 7:01
    
Though, I only have / listed with rw 0 0 flags, unlike the /dev mount point which does specify size=1514228k, hence how did you establish the rootfs space allotment on each VM test? And, is there a way to monitor use of the / tmpfs? In regards to what I am running, just to clarify, I haven't been running many of the programs / tasks listed in various comments to this question/answers concurrently with each other. –  user66001 Sep 16 '13 at 7:12
    
Lastly, thanks for your comments about not using a Live CD (I do appreciate that you justified the reasoning, and did so in a respectful way), but unfortunately the HDD state in these computers is the reason for using Parted Magic, I will keep the USB drive idea in mind though, and reconsider where the log files are being created. –  user66001 Sep 16 '13 at 7:15
    
i already mentioned /tmp and /run. /dev is a devtmpfs, similar to but not identical to a plain tmpfs - it contains all the device nodes for hardware in the system. it's not a directory you should use for anything else. –  cas Sep 16 '13 at 7:19
    
the size of a tmpfs defaults to half the total RAM. this can be overridden when the tmpfs is mounted using the size= parameter. see the mount(8) man page. changing the default is not likely to help you much, if at all - you're still limited to a total of 2.93GB shared between any mounted tmpfs filesystems, the kernel (including disk cache), and all running programs. –  cas Sep 16 '13 at 7:22

Parted shows the available memory on it's little "heads up" display (apparently called conky) in the top right hand corner. So you don't even have to work out how to get this information, it is already displayed. (As the available memory IS your free disk space left).

Parted Live CD heads up thingy-doodad

Or you may be running out of blocks or inodes, you may be able to infer this information via stat:

# stat -f /
   File: "/"
   ID: 0        Namelen: 242    Type: aufs
Block Size: 4096     Fundamental block size: 4096
Blocks: Total: 129061   Free: 127337    Available: 127337
Inodes: Total: 129061   Free: 128101
share|improve this answer
    
Thanks Drav. I had thought this would be the case also, but in each instance of suspected/explicit errors indicating out-of-space occurances, I have never been over 60% RAM usage, according to conky (For others: The program that is pictured above). If you know of a way to explicitly check the allocated / space of the type of filesystem Parted Magic uses, and/or the current status of that allocation, I would really appreciate it. +1 for the screenshot, though. –  user66001 Sep 15 '13 at 22:09
    
@user66001 another possible solution, it may be running out of inodes or blocks. –  Drav Sloan Sep 16 '13 at 17:47
    
Running stat -f / reports 4909 Free Blocks (out of 383970), and 168011 Free Inodes (out of 174877). –  user66001 Sep 17 '13 at 5:27

As I and others have said in the comments, you should not use Parted Magic as a normal distribution, it is not designed for it and is bound to have problems.

Anyway, that said, to check the space available you can just run df. I don't want to buy a copy of Parted Magic OS to test this, but the following is the output of df on a virtual machine running an Ubuntu Live CD:

enter image description here

Most of these are tmpfs style things (non of them are actual mounted partitions anyway) that exist in RAM. df can still accurately report usage. If you don't see a / entry under Parted magic, I guess they are using some kind of esoteric naming. Another hint that you are using the wrong tool for the job.

share|improve this answer
    
Please re-read the question. I have already tried df. This is what I see. P.S "I don't want to buy a copy of Parted Magic OS" - Parted Magic is free. I would have hoped someone providing an answer would have done some basic reading on this distro, before doing so –  user66001 Sep 15 '13 at 20:54
    
The only download link on the Parted Magic web site is a $4.99 "Buy Now" link - if there's a free download link somewhere, it's well hidden. It is free software, but if you want to download it without paying $5 you have to search for it on some other site. e.g. google for "Parted Magic torrent" –  cas Sep 16 '13 at 0:57
    
Thanks again Craig. @terdon - I must apologise on a part of my last comment. I haven't visited partedmagic.com since approx. May '13 (web.archive.org/web/20130511031605/http://partedmagic.com/…) when it was still free to download. This distro was hosted on sourceforge, and it seems (at time of writing this) there is stable versions up to June '13 still available there. –  user66001 Sep 16 '13 at 7:35
    
@user66001 no worries, glad you got your answer. Just remember we volunteer to answer your questions and I had actually spent a while looking into this trying to understand what you were doing. I had checked the website. Anyway, if someone gives you an answer that doesn't help, just ignore it and avoid the snarky comments ;) –  terdon Sep 17 '13 at 0:09
    
The comment was not intended to be snarky, but am not surprised this was taken this way. Without the nuances of in in-person communication, I seem to often word things as coming off with similar tones. However, there was the fact I had already mentioning trying df, and I cannot discount that how we got along at the start of this question, didn't affect my choice of words :( –  user66001 Sep 17 '13 at 20:53

I've run into this problem for years on live CD/DVD/USB distros like Debian, Ubuntu, Mint, maybe even Fedora if I recall. Memory used by overlayfs (the currently used fstype for live Mint/Ubuntu) and tmpfs are hidden in free 's cached memory (and /proc/meminfo's Inactive entries), along with temporary disk read caches, so it's unclear how much memory is really "free".

I'm using df to add up all the space used by overlayfs & tmpfs, and subtracting it from the free + buffers + cached info from free. I'll have conky highlight that number next to it's misleading "free ram". All sizes are in K's.

If your distro's live version doesn't support df then I don't know where to look for info on overlayfs/tmpfs. mount, /proc/mounts and /etc/mtab seem to only show maximum or no sizes, not current size like df does.

First for the space used by overlayfs & tmpfs,

overlayfsused=$( df -t overlayfs --total |tail -n 1|tr -s [:space:]|cut -d " " -f 3 )
tmpfsused=$( df -t tmpfs --total|tail -n 1|tr -s [:space:]|cut -d " " -f 3 )
diskused=$(( overlayfsused + tmpfsused ))

FYI, df's -t only shows that type of fs (could put both into one df), tail only gives the last total line, tr compresses whitespace to a single space so it's easier for cut to cut the right field out.

And for the free ram you can parse free 's output (probably easier) or read from /proc/meminfo (I already tried & typed it this way):

free=$(grep MemFree < /proc/meminfo |tr -s [:space:]|cut -d " " -f 2)
buffers=$(grep Buffers < /proc/meminfo |tr -s [:space:]|cut -d " " -f 2)
cached=$(grep "^Cached" < /proc/meminfo |tr -s [:space:]|cut -d " " -f 2)

Then put it together, say for a nice script output that conky can exec or execi every minute or two:

realfree=$(( free + buffers + cached - diskused ))
echo "$(( realfree / 1024 )) MiB"

I'd even consider an if realfree < 100M then display warning message, del temp files, sound red alert, etc...

As to using a live distro for daily use, the whole point of Ubuntu's (and many other) live versions is to try out a distro for regular "daily" use for a few hours and see if you like it. And many online banks and security-conscious articles specifically recommend using a live distro for secure online banking and the like. The fact that the live distros don't realize when they really run out of ram is IMO a bug. I was able to crash a live Mint just by copying big files to $HOME and /tmp since they're both using ram, and both have a max size of 1/2 ram. FYI Currently Mint's got possibly half of ram used by each of / (overlayfs), /dev (devtmpfs? only 4k used so I'm assuming it's normally tiny), /tmp, /run/shm

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.