RAMDisk v2 - Store files in memory with almost unlimited capacity!

This is a simple program to use, so I'll just get to the good bits:

Usage:

ramdisk
(or any other arguments that are invalid)
This will display any loaded images, and display the proper usage.

ramdisk create <drive name>
This will load a blank image, with the name of <drive name>, which is used to access it.

ramdisk load <filename>

If <filename> points to a file:
This will load an image saved at <filename> by ramdisk save.

If <filename> points to a directory:
RAMDisk will create and load a new image with the name of the directory, and copy the contents of the directory to the new image.

ramdisk unload <drive name>
This will unload any image with the name of <drive name> that is currently loaded.

ramdisk save <drive name> <filename>
This will save the entire contents of the loaded drive with the name of <drive name> to a file specified at <filename>.
This will not save the files to an individually accessible format, instead it saves an archive.

Link: http://pastebin.com/izMaKme5

pastebin get izMaKme5 ramdisk

This requires my Virtual Filesystem API which should be automatically downloaded by RAMDisk itself, but if it does not, then use this:

pastebin get ZT1euz3x vfs

Please post any suggestions or bug reports!

Wow this seems really cool, Actually had an idea about creating something like this once( but I was too lazy xP )
I will test this tomorrow and give you more feedback, gotta get some sleep you know :P/>

Yea, this does look pretty sweet.

Does anyone know what the memory limit for CC is?

In my OneOS rewrite I've been thinking that I might be starting to push it.

oeed, on 27 June 2014 - 01:07 AM said:

Does anyone know what the memory limit for CC is?

LuaJ has no memory limit, but it's generally a good idea to not use absurd amounts of it.

ROFLCopter64bit, on 27 June 2014 - 02:46 AM said:

oeed, on 27 June 2014 - 01:07 AM said:

Does anyone know what the memory limit for CC is?

LuaJ has no memory limit, but it's generally a good idea to not use absurd amounts of it.

i would actually hazard a guess and say that the limit is whatever the limit of Minecraft is set to, so if you use too much Minecraft could start to give you memory warnings.

theoriginalbit, on 27 June 2014 - 02:49 AM said:

ROFLCopter64bit, on 27 June 2014 - 02:46 AM said:

oeed, on 27 June 2014 - 01:07 AM said:

Does anyone know what the memory limit for CC is?

LuaJ has no memory limit, but it's generally a good idea to not use absurd amounts of it.

i would actually hazard a guess and say that the limit is whatever the limit of Minecraft is set to, so if you use too much Minecraft could start to give you memory warnings.

Well, if that's the case, as it probably is now I think about it, then loading a few hundred kilobytes of various APIs won't be the end of the world.

Couldn't this also be used to make a Temporary Files directory that automatically flushes when people reboot?
Could be useful for implementation in an OS that makes a bunch of temporary files.

oooo I should make a ramdisk and put all my important files on it then delete the files on the normal disk! that sounds like a great idea!!! *griefer comes in and shuts off computer* FUUUUUUUUU!!!!!
But anyhow yeah, great for temporary storage.

Oh wow! This looks great!

A way to store things forever using this system would be good though…


Maybe have it save the contents of the files into a sort of /tmp directory when the computer shuts off, and then when it turns back on save all the files back to ramdisk… hmm….

Sir_Mr_Bman, on 13 July 2014 - 12:06 PM said:

Maybe have it save the contents of the files into a sort of /tmp directory when the computer shuts off, and then when it turns back on save all the files back to ramdisk… hmm….

Maybe it could save it to an equivalent of hiberfil.sys in Windows, but the problem is there is no real way of handling when the computer shuts on or off, so that's going to be a problem.
On that note, my virtual filesystem API needs an update, and I'll probably implement something like autosaving the image files.

i just realized you made a virtual folder. could you please make this work with rednet so you can have an image that is an actual folder on another server, and will syncronize and stuff

oh and in what emulator did you make this screenshot?

wilcomega, on 15 July 2014 - 10:25 AM said:

i just realized you made a virtual folder. could you please make this work with rednet so you can have an image that is an actual folder on another server, and will syncronize and stuff

oh and in what emulator did you make this screenshot?

Already planned.

CCEmuRedux

Finnaly, thanks for doing this, I was searching and trying to make this for 6 months now…

Sugestion: Read-only drives… Also, run from website.. So, just like OneOS(I think it needs more space), it could run the ramdisk from the web and the OS would use those files within the read-only drive

logsys, on 15 July 2014 - 12:02 PM said:

Sugestion: Read-only drives.

Already in the API, I just need to finish it

logsys, on 15 July 2014 - 12:02 PM said:

Also, run from website.

What do you mean by this?

ROFLCopter64bit, on 15 July 2014 - 12:15 PM said:

logsys, on 15 July 2014 - 12:02 PM said:

Also, run from website.

What do you mean by this?

Do you see pastebin run <blahblahblah>?? doing like ramdisk load <link> would create a ramdisk without having to save a current ramdisk

logsys, on 15 July 2014 - 12:02 PM said:

Sugestion: Read-only drives… Also, run from website.. So, just like OneOS(I think it needs more space), it could run the ramdisk from the web and the OS would use those files within the read-only drive

That'd actually be pretty cool. Although downloading 400-600KB could be rather slow…

logsys, on 15 July 2014 - 12:21 PM said:

Do you see pastebin run <blahblahblah>?? doing like ramdisk load <link> would create a ramdisk without having to save a current ramdisk

Oh, I see now. Compression might be needed though.

oeed, on 15 July 2014 - 12:31 PM said:

That'd actually be pretty cool. Although downloading 400-600KB could be rather slow…

I've been playing with a RAID implementation in CC, and I don't think the ability to split drives into chunks and download those simultaneously would be hard to help the speed, if it does at all.

ROFLCopter64bit, on 15 July 2014 - 12:41 PM said:

oeed, on 15 July 2014 - 12:31 PM said:

That'd actually be pretty cool. Although downloading 400-600KB could be rather slow…

I've been playing with a RAID implementation in CC, and I don't think the ability to split drives into chunks and download those simultaneously would be hard to help the speed, if it does at all.

Well, in terms of 'streaming' a program, you'd have to wait until all chunks were downloaded, otherwise you'd have files that don't exist. RAID in CC sounds pretty awesome, it would allow data centres for Firefolf/similar services.

oeed, on 15 July 2014 - 01:01 PM said:

RAID in CC sounds pretty awesome, it would allow data centres for Firefolf/similar services.

Would RAID 5/6 be needed in in this situation? My RAID 0 is just a hack of union points which hides the true location of the directories, and RAID 1 technically just hides one drive, then takes all the input from the other drive and mirror it.

I'm working on a new update, which helps it handle massive images and drives (>100kb, i'm guessing), but I seem to be running into a wall.
To copy a 200kb file to a ramdisk, it takes 98 seconds (1:38) and saving the same ramdisk creates an archive about 2.6MB, which is a massive 1250% of the original size.
The first problem (and by a minor extension second) would be easily fixed by saving each file's data as a single string instead of a byte array, but due to LuaJ not properly converting bytes to their character counterpart, files would be corrupted. The second problem could be fixed by not serializing the table to be able to save it, but I do not know of a method to do so. (If someone could direct me to a much better method it would be greatly appreciated.) It could also be fixed by using a compressor, but that uses much more time to process and when I used a compressor to check if it could be done, it really struggled to the point of failing.
I'm still working on a RAID implementation I discussed earlier, and I guess this is the beginning of the "Huge Data" era.

I've been working on solutions, and I'll post my progress so far:

• The time it takes to load from a saved archive is now reduced to (almost) nothing, by putting a 'return ' at the start of the archive and using loadfile() to give it instead of the bulky unserialize
• Archives are now reduced to a 300% ratio instead of the 1250% by removing almost all whitespace, and instead of storing numbers in the archive, it now saves the hex counterpart for a tad more compression. (I doubt I can even get it down to 200%, as anything lower would require saving it in binary mode, which takes too much time)
• I'm working on rewriting the virtual filesystem API so that it holds a hex string instead of a table of bytes for each file, which should decrease the archive size even more and make loading anything instantaneous by using this as a sidestep to LuaJ's >128 ASCII issue.

Just as a heads up, archives saved in version 1.0 will be incompatible with 2.0. Copy the files over instead. (Not ramdisk save.)

Version 2 has been released, you can download it now via the same pastebin link.
It should tackle issues related to big files which was it's prime purpose. Keep an eye on this for a FTP implementation in the works.

so it's like tmpfs on [CENSORED].

Wow, such improvement.. although just had an idea now for a use fron that