51–60 of 83 posts
Surprised no one here has mentioned mfsBSD. It's an unofficial FreeBSD answer to this problem. Works very well for some maintenance tasks, like ensuring a new install's disks are clear of partitions/zpools. I have even booted it's ISO via IPMI over the internet with OpenVPN. https://mfsbsd.vx.sk/
Earlier quoted context omitted.
I can't hard-core prove anything, but I've read the theory on how if I'm accessing warm disk cache, putting things into a RAM disk shouldn't speed them up, and every time I've done it and tested it, putting things in a RAM disk is faster than having it on disk, even when the very act of copying the stuff into RAM should definitely have just warmed everything up just before the test. I've not done it very often, but e…
Interesting! Did you make sure there aren't any writes happening in the warm disk cache case, even for things like atime?
Out of curiosity, does data persist after a shutdown when an OS runs on RAM? Are there dumps to a HDD?
Nope. The piratebay used to run their servers like this. They'd boot off of a USB stick, pivot root to a ram disk, and then unmount the USB stick. Then when the cops would seize the machines and cut power to save as much evidence as they could, they'd actually be doing the opposite.
Let's for a second assume that forensic computer technicians aren't completely incompetent and actually understand that you do not pull the plug on a system that potentially contains evidence the first thing you do.
While this has been known to happen in the past, I can almost guarantee it's because of "helpful" police officers, much in the same way the job of any forensic technician can be ruined by good intentions of those who don't know better.
I believe FreeNAS does something like this during startup. You can “install” it on mirrored USB drives in case you run out of power. The redundant USBs are used to install the OS back into RAM. An extra USB in case of corruption and they’re way cheaper than SSDs. I’m assuming you still need to write config files back to the USB. FreeNAS prefers ZFS so it’s RAM hungry anyway. The article recommend 500mb more than you…
SSDs cost 26€ for 128GB and offer significantly more performance and reliability. USB drives are not significantly cheaper.
Because this is a "real" (headless) 2U server, none of the USB ports were being used so, while dedicated SSDs for the boot volume would be nice, a pair of decent 16 GB USB flash drives have been doing a wonderful job serving as my mirrored "freenas-boot" pool.
"Please note that this prompt (y/N) defaults to yes with a 15 second timeout if 4G or more of RAM is detected" I understood the capitalisation to indicate the default. Or does the default change? That seems bad if you're intending to wrap this in a script.
I wonder whether this achieves anything performance-wise that just cat'ing every file to /dev/null to warm up the buffer cache wouldn't achieve. In theory, the kernel uses a buffer cache that will hold on to disk pages until they're invalidated by writes. It'll evict the cache if there's memory pressure. But this setup will presumably just crash if there's memory pressure, so that doesn't seem like a win for the RAM…
I'd agree that making ureadahead more aggressive would indeed make more sense than just sticking your roots in RAM. It shouldn't impact your boot time very much and is much more flexible!
But maybe there's some special perf benefit to the ramroot approach..
Earlier quoted context omitted.
Nope. The piratebay used to run their servers like this. They'd boot off of a USB stick, pivot root to a ram disk, and then unmount the USB stick. Then when the cops would seize the machines and cut power to save as much evidence as they could, they'd actually be doing the opposite.
> Then when the cops would seize the machines and cut power to save as much evidence as they could, they'd actually be doing the opposite. Let's for a second assume that forensic computer technicians aren't completely incompetent and actually understand that you do not pull the plug on a system that potentially contains evidence the first thing you do. While this has been known to happen in the past, I can almost gua…
And this piratebay mitigation was in the early 2000s. At that point most of the anti forensic mitigations were booby traps on input channels (keyboard, console, etc) and maybe a tilt sensor that'd wipe the drive if anyone tried to access it. Under that scheme, pulling power before inspection is what you want to do.
I would love to see this feature added to CentOS/RHEL. In the past, we used NFS Diskless which is anything but diskless. Hacking together an initrd that loads everything into ram is, well, hacky. To have a dracut function or a toggle to enable this would be great for lightweight deployments, testing, labs, vagrant, etc... I'm sure that RHEL must have been contemplating it because there is /etc/sysconfig/readonly-root…
We use warewulf (via openhpc) for diskless centos 7 compute nodes at work. Basically initramfs creates a tmpfs, downloads the OS image to it, switches root to it.
Earlier quoted context omitted.
One of the big advantages is that you do not need to install file systems on your storage for single purpose servers, which allows your application to run on top of the raw block devices. Databases and similar run much better in this configuration (assuming they support raw block devices), especially if you are running on top of a hypervisor.
Do you know of or could list which databases support raw block devices?
I started implementing raw block device support for my own databases about five years ago and it turned out to be brilliant for more reasons than I expected. I should have tried it much sooner. Ironically, it requires less code than using the file system.
What do so something cool? Boot a whole computer cluster using BitTorrent as a backend, diskless, diskfull, at lightning speeds: https://github.com/dchirikov/luna