mount RAMFS at root like other disks and make it less hidden

[pulkomandy]

RAMFS is a generally useful thing to have. It can be used to store work in progress files that don't need to be stored on disk (people have been using a ramdrive to run haikuports in, for example).

Currently our RAMFS is mounted in /var/shared_memory and is hidden (not visible as a volume in Tracker, not visible in mountvolume, ...). I think we should make it more clearly visible to users:

• Mount it in / like all other disks
• Show it on the Desktop like all other disks (or in the Disks Tracker window for people who use that)

/var/shared_memory can be a symlink to it (or to a subdirectory inside it).

/tmp could also benefit from being a link to RAMFS instead of being stored on disk (this would speed up gcc compilations when not using -pipe)

[pulkomandy]

Precedent for this: on Amiga systems, the T: volume is like this. I think some Amiga systems manage to offer a reboot-resistant RAMFS, which keeps its data accross reboots. It would be quite cool to achieve this, but seems difficult to implement in the modern world?

[waddlesplash]

We should probably handle sizing and quotas better in RAMFS before using it so broadly I think.

[X512]

It maybe better to have separate RAMFS mount points for memory files used by software and regular user files.

[bipolar]

Replying to pulkomandy:

I think some Amiga systems manage to offer a reboot-resistant RAMFS, which keeps its data accross reboots. It would be quite cool to achieve this, but seems difficult to implement in the modern world?

While not RAM FS, but a RAM Disk... Sounds like ​AGMSRAMDiskDevice (I used it a lot 20+ years ago :-D)

[waddlesplash]

We already have a ramdisk capable of being file-backed I believe? Or at least loaded and written to files.

[pulkomandy]

The main difference is that a ramfs is not a block device, so:

• it will use RAM only if you fill it with files (however our own ramdisk does allocate ram on-demand and supports trimming with fstrim)
• it does not need to be formatted
• it can grow up as needed if you #uddenly need a lot of files on it

When I say the ramdisk on Amiga is reboot-resident, I don't mean file backed: they just keep it in non-erased RAM during reboot, and so you find the contents back after rebooting. But that will probably not be possible with ramfs. Basically it would mean reserving a fixed physical address range, and hoping that the bios doesn't clear it.

[pulkomandy]

We should probably handle sizing and quotas better in RAMFS before using it so broadly I think.

Do you have link to relevant tickets? Is that #18126? (just to make sure we don't have any "known" limitations that are not properly traced)

[waddlesplash]

Yes. Though that ticket could probably use some elaboration...

[KitsunePrefecture]

Me also wanted to use it for Virtual Memory, I assume that is like swap file on other OS. I have 32 GB in this WST grade laptop and I am on 32bit Haiku. Actually I cannot use anything of it as shows always that used 0 bytes of it. At least it seems using df -h command. Generally I remembered so it was everyone happy it accelerates browsers as well, - I do not know even browsers Web, Webpositive really using it automatically or how can I switch on for them to use it.

I would be happy if I can benefit from my available RAM somehow to accelerate the OS itself or apps running on top of Haiku.

Thanks,

[pulkomandy]

You want to put virtual memory in a ram disk? Virtual merory is used when you don't have ram anymore. The ram disk is stored in ram. So that makes no sense.

webpositive does not need this at all. It was put there specifically for gtkwebkit. "makes web browser fast" makes no sense, it is specific to each engine.

also, we don't need random user comments on the bugtracker. Please use it only if you have a bug to report. For other things please use the forum.