98 posts
Location
Australia
Posted 22 June 2014 - 11:09 AM
RAMDisk v2
Warning: This is not a replacement for persistent storage, so when you turn off / crash the computer, any loaded images will be removed without saving!
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/izMaKme5pastebin 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!
Edited on 14 August 2014 - 03:17 AM
1852 posts
Location
Sweden
Posted 27 June 2014 - 12:50 AM
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/>
2151 posts
Location
Auckland, New Zealand
Posted 27 June 2014 - 01:07 AM
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.
Edited on 26 June 2014 - 11:07 PM
98 posts
Location
Australia
Posted 27 June 2014 - 02:46 AM
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.
7508 posts
Location
Australia
Posted 27 June 2014 - 02:49 AM
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.
2151 posts
Location
Auckland, New Zealand
Posted 27 June 2014 - 03:35 AM
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.
3 posts
Posted 27 June 2014 - 11:27 PM
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.
1029 posts
Location
Missouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension
Posted 02 July 2014 - 10:48 PM
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.
63 posts
Posted 13 July 2014 - 12:06 PM
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….
98 posts
Location
Australia
Posted 13 July 2014 - 12:55 PM
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.
453 posts
Location
Holland
Posted 15 July 2014 - 10:25 AM
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?
Edited on 15 July 2014 - 08:26 AM
98 posts
Location
Australia
Posted 15 July 2014 - 10:44 AM
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
162 posts
Posted 15 July 2014 - 11:57 AM
Finnaly, thanks for doing this, I was searching and trying to make this for 6 months now…
162 posts
Posted 15 July 2014 - 12:02 PM
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
98 posts
Location
Australia
Posted 15 July 2014 - 12:15 PM
Sugestion: Read-only drives.
Already in the API, I just need to finish it
Also, run from website.
What do you mean by this?
162 posts
Posted 15 July 2014 - 12:21 PM
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
2151 posts
Location
Auckland, New Zealand
Posted 15 July 2014 - 12:31 PM
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…
98 posts
Location
Australia
Posted 15 July 2014 - 12:41 PM
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.
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.
2151 posts
Location
Auckland, New Zealand
Posted 15 July 2014 - 01:01 PM
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.
98 posts
Location
Australia
Posted 15 July 2014 - 01:21 PM
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.
98 posts
Location
Australia
Posted 23 July 2014 - 11:31 AM
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.
98 posts
Location
Australia
Posted 27 July 2014 - 03:20 AM
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.)
98 posts
Location
Australia
Posted 14 August 2014 - 05:16 AM
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.
53 posts
Posted 14 August 2014 - 08:42 AM
so it's like tmpfs on [CENSORED].
Edited on 14 August 2014 - 06:42 AM
162 posts
Posted 10 October 2014 - 03:24 PM
Wow, such improvement.. although just had an idea now for a use fron that