Well, hard drive died, at least on this laptop. Had a small run, since i hardly used this computer but oh well.

Anyways, got Mint installed, and it's working, although some issues (like how to get the friggen ZRam thing to work properly) but otherwise it's pretty smooth sailing.

So, decided i'd try a game. Downloaded the Shenzen IO game as a test, although marked for Ubuntu it installed quite seamlessly and runs without question; The installer for Linux looks a little different than it's Windows counterpart. (Although i do have WINE for when i need it, already using it for an app or two).

I remember using Redhat 4-6 back in the late 90's. That takes me back...

Anyways, Hopefully remains smooth sailing as i finish setting things up.

What do you switch to when the next hard drive fails?

ZRam?! You're scaring me… :-O

I've thought about using GNU Linux. I've tried maybe a dozen different "brands", some I couldn't get installed. I made notes each time for where they are located, how to install, and whether I succeeded with the installation. More notes about what worked and didn't work, and how it fit with my interests or didn't. Someday, I'll try again and refer to my notes to help me out.

Even though having Mac hardware has been an impediment to me when I've tried installing GNU Linux, there's been too much fluff and "features" in even when I have succeeded installing into virtual machines. And way too much similarity to MS Windows and macos. I want a different experience, a different set of opportunities, not the same thing again, otherwise there's no reason for me to switch. Might as well be selling agricultural pesticides made from the same ingredients but are now organically grown or natural. *sigh*

ZRam… ZRam! ZRam?! Besides never hearing of ZRam, the thought of having to do any computer engineering to keep the operating system working gets me cringing. I really don't understand why GNU Linux developers (or developers of any operating system) still have so much trouble making something simple and self-maanged after all of these decades. It seems to me there's just no alternative at all. Not meant to be depressing or anything…

Probably a ball-peen hammer :P Supposedly still in development, but a move from zswap/compcache which was a compressed swap space. Basically take a block of ram, treat it as a swap device, then when you get low on ram, compress it and put it in the compressed space, gives you more ram (more or less).

I was trying to follow instructions for compressing a filesystem, which many suggest the -o discard option, but i can't get it to work, meaning either it doesn't work, or it's not implemented. Not sure. Not that i need a compressed FS that often, but when you have a 200MB archive that expands to 3GB, and trying to view/use or recompress temporarily, no need to write it on the hard drive. Yeah, and unless you know what the 'fluff' is it will often just take up space.

I remember a linux rescue disk pair that i got for 2 floppies. No fluff there! (Busybox is your friend). But most of the fluff is likely GUI and related, and eyecandy you don't need when you just want to work and not have all these effects that are silly and superfluous. If i can i prefer going lightweight as much as i can, but still have all the features (and major programs) that i wanted.

I hope you enjoy Ubuntu's table scraps. Considering that Ubuntu is the leftovers of Debian.

If you used Red Hat back in the day, why did you not decide to use Fedora?

If you have enough RAM, you can just extract it on a tmpfs and it likely won't hit the disk.

Hmm i did use Fedora Core for a little while. But it didn't become Fedora Core until later.

Although the big reason to switch to windows, is due to hardware incompatibilities, when 1-2 things on your system don't work at all (and you need them) well... Tried that, the tmpfs was locked at half the ram size (2GB), although i can probably override it that is already done for now.

I'll probably make my whole /tmp folder use tmpfs, i'm not doing that much on my system for it to be a problem.

Interestingly enough, I can think of 4 different ways to get something like a ram disk on Linux. (If you don't know which one you want, you want tmpfs.)

1. The old ramdisk driver (brd). With this kernel module, you can create a number of ramdisks, all the same size, with the first one being (IIRC) /dev/ram0. After inserting the module, you can make a file system on the device and then mount it. One downside is that the size is fixed at creation, and will always consume the full amount of ram.

2. Use ramfs or tmpfs. These are in-memory filesystems, and unlike the brd driver, will only consume the amount of memory actually needed to store the files. (The half ram limit is there for safety, and it can be changed when mounting (or remounting, which is handy because it won't erase existing files.) The main difference between the two is that tmpfs can be swapped to disk (if you have swap configured), but ramfs will always remain in memory (and filling memory with ramfs can cause a kernel panic). (One other difference I noticed; you can create a swap file on ramfs (not that there is any point other than perhaps testing the swap mechanism), but the kernel won't let you do this on tmpfs, with good reason; using the loop device to work around this restriction is a good way to deadlock the kernel, locking up the entire system.) tmpfs is the simplest way to get a ramdisk on Linux, and is recommended for most uses. Note that there is no need to create a filesystem, as ramfs and tmpfs are filesystems rather than devices. (If you actually need a specific file system for whatever reason, there's always the loop device.)

3. Use zram. This module creats a number of block devices, but you have to activate them individually by writing to files in /sys/modules/zram. The notable characteristic of the zram devices is that the data is compressed in memory, which saves RAM at the cost of CPU cycles. Note that you do need to create a filesystem on this device for it to work. One use for zram is to put swap space there.

4. Use phram and mtdblock. This is a highly specialized approach; you need to find some area of physical memory that the kernel isn't used, and you can use these modules to tell the kernel to treat that region of memory as a block device, allowing you to make a filesystem here. The uses of this mechanism tend to be rather specialized; accessing the ramdisk created by the MEMDISK utility (from syslinus) is one use, while I've read about it being used to use GPU memory as swap. I've also seen it as a way to be able to access kernel memory or hardware registers from userspace, which is occasionally useful for kernel or hardware debugging. That's only an upper limit set at mount time, and it can be changed by remounting the filesystem (mount -o remount,size=13G to change the size to 13 gigabytes, for example).

yeah hadn't gotten to that, but the big problem was already resolved with it, although I'll remember remount next time. yeah, got zram to 'work' technically, although the filesystem drivers still see them at their allocated size. zramctl tells me how much it has compressed on them, but df tells me they are full. So it will say like 512MB, 400MB used, 138MB comp, 272MB free, but df says 402MB used and 110MB free.

I've seen multiple references for doing a filesystem like: mount /dev/zram0 /mnt/ramdrive -o discard, but that doesn't give it more space when it becomes available. Seems like it's more a sparse file but i'm not well versed in how those work either. hmmm... I mean it's a low priority.

One little trick is to fill the free space of a zram filesystem with something easily compressible, like the contents of /dev/zero; this will clear deleted files from memory and reduce the space taken up by the device. Just write the zeros to a file, and then delete the file afterwords.

Unfortunately, one limitation of zram is that you can't change the allocated size of the device on the fly. You need to unmount the filesystem, deactivate the device, and then give it a new size. (You could, of course, make a filesystem on only part of the device and then enlarge it later, or use something like lvm or btrfs on zram devices, but that is getting rather complicated, though it might be an option if you want to learn how those technologies work.)

A sparse file is a file that's logically very large, but only has data written to parts of it. Therefore, the filesystem only needs to store the parts of the file that contain non-zero data, and can just leave out the sectors that contain nothing but zeros. This has the advantage of saving disk (or filesystem) space, but has a few drawbacks; writing to the middle of the file could trigger a disk full condition, and such files are more prone to fragmentation.

Incidentally, in scientific computing, there's the notion of a sparse matrix, or a matrix where most of the elements are zero; the principle here is the same, allowing one to work with large matrices that contain mostly zeros.

Not sure but i think the zram module and the tmpfs are pretty efficient already without having to zeroize it. Plus if i had a bunch of 0's to the zram, it will just compress it and stay at the beginning, since i don't have direct control over the block of memory...

For a sparse file, i would think there'd be 2 structures involved. The first is a bitmap of which sectors are used in the allocated memory. The second would be a pointer to the blocks, thus fragment-able but still workable. Course i'm thinking more like a COW system. And in ram it doesn't matter how fragmented it gets, since you can re-arrange and fix it fairly simply, while on a actual device is a little more annoying... Well using a combination of zram (compressed swap) and tmpfs. trying to control the settings is annoying, at least for automatic startup. 1-2GB zram (lzo so very fast). so far the zram hasn't been touched at all.

The zero file trick is best used after the filesystem of zram has been used for a while and has had files deleted from it. Filesystems don't actulally clear space that a deleted file previously occupied; they only mark that area as available for re-use; by writing zeros you actually clear out the unused space to allow for better compression. (This sort of thing is actually why the TRIM ATA command exists, and Linux supports that operation for loop devices (over sparse files) as well.)

I think that description of a sparse file is pretty accurate. A discard operation on a filesystem on a sparse file, when supported, can be implemented by clearing part of the bitmap and re-adjusting the block pointers (assuming that's the chosen representation).

If you're curious about how sparse files actually are represented in Linux files, you can, of course, look at the source code.

I've used sparse files to help me manage a series of virtual machine files. They would not fit the space available on the machine I was using, but once I forced copied them as sparse, everything went well and they took only about 20% of the bits they wanted initially.

Alternatively, btrfs allows you to compress everything on the fly. Also, FUSE supports some compressed archives, so you can mount the compressed file directly.

This is why Linux is nice: lots of solutions. On Windows I would not know where to start looking. I have tmpfs mounted as /tmp and /dev/shm. Is there any reason for the second one? Is is a new standard thing to ensure a tempfs on the systems?

It is quite warming to hear you say that. Thanks. I'm counting on it for when trouble strikes.