Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a tmpfs with 14gb of allocated size. I have 16gb of ram
I have a single 6gb file on HDD which I attempted to split into 200M chunks into my tmpfs
Code:
split ~/Downloads/RAW.tar.bz2.gpg -db 200M image_
Logically, 6gb of split files should not overwhelm a 14gb tmpfs.
The first time I ran it though, I think the whole X display server crashed. It restarted and brought me back.
Of course, I had to try that again.
So I ran it again and this time it killed my firefox process (using ~1gb of ram), then the time after that it killed banshee.
I thought tmpfs prevented you from using more space then possible & crashing other programs?
You fill memory when it fills. If the system needs memory and can't get it - programs get aborted.
That is the problem with tmpfs. It really wasn't supposed to be used for /tmp. Originally, it was for lock files, small credential files that get deleted on logout; it works well for pid files recording service information.. It shouldn't be used for user storage though as it is trivial to create a denial of service condition.
If you have given tmpfs 14GB (out of 16GB), then you only have 2GB for running the system. You can actually take the size of tmpfs (actual usage) and subtract it from your memory size, and that is all you have...
You can try adding more swap - but your system will slow down a lot.
But it is entirely possible to kill a system with it.
ANY filesystem that users can write to is not exactly controllable. tmpfs doesn't support quotas (it can't as you would have to reload them on every boot).
And the way RH/Fedora uses them permits a DOS every time. User files in /run allows a user to fill that filesystem - which is used for every login. Fill it, no logins. Not even root. System services cannot be restarted.
I have a tmpfs with 14gb of allocated size. I have 16gb of ram
I have a single 6gb file on HDD which I attempted to split into 200M chunks into my tmpfs
Split command might require a lot of RAM to deal with your huge file. In fact it operates in RAM, not in tmpfs. Tmpfs is just a storage. And seems your 2Gb of RAM too small for entire the system plus split (which tries to deal with 6Gb file inside 2Gb of RAM).
I think you need to create tmpfs as little as possible to fit your file, something like 6Gb or a bit large. But it should be enough to fit your file. This case you will have almost 8Gb of RAM for your system. And split will be much more comfortable with 8Gb of RAM than with 2 Gb.
But it will induce a large buffer pressure, that in competition with normal system usage could push the system into OOM with only 2GB available. (first source I found was from BSD, in the answers to a question of getting the source: https://groups.google.com/forum/#!to...sc/7SwF9wEc21Q)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.