I've put together a very simple how-to for using RAM on one computer as SWAP for another computer. This simply uses nfs to share a swapfile located in a tmpfs ram disk. This technique is a great fit for my "poor man's SSD", RAMboot.

RAMboot is blazing fast, but it eats up a good chunk of RAM. By combining it with nfs tmpfs swapfile, less used files are offloaded to the RAM of another computer.

http://www.linuxquestions.org/questi...omputer-37197/

Thanks for the ideas. Almost an answer to a question no one ever asked. I mean that in a nice way. You are doing good work. Keep it up.

Thanks! It's something that I started thinking about when someone posted that they had gotten their hands on a bunch of identical computers with 8GB or RAM, each, and 1TB spinning hard drives.

But I never experimented with it until the other day, when I was frustrated by a computer with 2GB of RAM getting sluggish when I opened too many heavy web browser tabs. I thought...hmm, let's give that nfs swap idea a try! Even though the server in this case has an SSD, I decided to use a swapfile in tmpfs anyway just to prove the technique works. The performance bottleneck is the gigabit nfs connection, so there would be no performance difference between putting the swapfile on the ssd or in a ramdisk.

Link this post to that question. I remember that question too.

Guess someone did ask that question.

I found that thread, "Older PCs with 1TB drive want to combine all space".

http://www.linuxquestions.org/questi...ce-4175589424/

Thinking about it more, I think the combination of RAMboot with the tmpfs nfs swap is the way to go for high performance "poor man's SSD". I'll be setting up my most powerful workstation that way (an i5 Mac Mini, which unfortunately can't be upgraded to an SSD without crazy computer surgery.)

But I am pondering a modification to RAMboot which makes it a bit more usable as a main workstation - using rsync to keep /home synced up with a local or nfs backup. The way RAMboot works, you have to do a full backup of the OS partition whenever you want to save the current state back to disk. Depending on the specifics, that could take a few minutes.

I'm thinking it would be nice to have a startup script in /etc/rc.local rsync /home from a backup, and to set up a taskbar icon to run a script that rsync's ~ to the backup. That might only take a few seconds, and it provides a nice way to keep things synced up in case of power failure or you just want to shut down to add/remove hardware or something.

This adds a little complexity to RAMboot, but it gives a lot of usability.

I think it might ultimately show less promise on network speeds but worth testing.

I don't see how this would qualify as a "poor man's SSD". Yes a ramdisk is fast, but ethernet (even gigabit) is even slower than an HDD. Why would you do this instead of just using a swap file on the local HDD? I can't imagine it's much, if any faster.

It is a LOT faster than a local hard drive. A typical spinning hard drive is maybe a little bit faster sustained, but the seek times kill performance. You get no where near the theoretical sustained transfer rates...instead, you get a lot of waiting and thrashing. The ~100MB/sec for RAM on another computer is very zippy in comparison.

If you have a local SSD, though, use it! It'll be quite a bit faster than RAM on another computer.

I actually thought that a local HDD would be almost as good, if not better, which is why I didn't try it for such a long time. But when I did it, I was very pleased at the performance. My computer with 2GB of RAM no longer grinds to a barely usable crawl when I open up too many heavy web page tabs.

I've been pondering either compressed sshfs or nfs via a compressed ssh tunnel for swapfile. (I'm not sure yet whether a swapfile will work over sshfs the way it works over nfs.) This might mitigate the bandwidth issue at the expense of using CPU.

Doing a little research, I think swap over sshfs won't work out. Besides the problem that it isn't a block device (but I think that can be worked around with a loopback), there's the problem that sshfs runs in user space. That means that the sshfs module itself may be swapped out. So I must restrict myself to what's available within kernel space.

zram on the client side looks like it won't work either. Looks like zram only really works well if it's the only swap. Otherwise, it tends to compress the pages which are least likely to be needed again. After it fills up, remaining pages will go to the next priority (slower) swap.

OTOH, zram is a block device, so it might be useful for me as an actual file system partition rather than a swap partition. I'm still trying to figure out good places where it can fit in (maybe client, maybe server, maybe a combo).

zswap looks closer to what I'm looking for. It basically acts as a compressed cache for swap. Thus, it will tend to compress the pages which are most likely to be needed again. Unfortunately, when it does write to the slower swap, the uncompressed pages are written to the slower swap.

Trying to tunnel nfs over ssh looks like way more trouble than it's worth. I'm not positive, but I think it suffers the same user space vs kernel space issue of sshfs (making it a non-starter). And more generally, getting nfs to work over an ssh tunnel is itself a bear due to the way nfs uses arbitrary multiple ports.

Worth playing with.

I take back everything I said before about the speed boost of RAMboot being disappointing. My previous results were disappointing simply because I was doing them on computers that were CPU limited already. But now that I've converted my fastest computer to RAMboot (an i5 2011 Mac Mini with 8GB of RAM)...damn. It is FAST. Netbeans opens up much faster, and chromium opens up in an instant.

Right now I'm doing everything without any compression anywhere, and I have a tmpfs shared swapfile to another computer's slow SSD (the SSD is only about 77MB/sec sustained, so it's actually slower than the ~100MB/sec that the gigabit ethernet connection provides). I was actually already happy with the speed that this gave me, using the slow SSD for nfs root. But the speed was sluggish compared to RAMboot.

I have adjusted my RAMboot how-to blog, to reflect my new thoughts, and also adding an rsync technique that lets you save just your home directory. This is good, because the full snapshot takes a few minutes. Just doing an rsync on your home directory takes less than a second.

http://www.linuxquestions.org/questi...-jessie-37165/