I think an interesting and trivial to implement feature would be to have a RAMDISK available as a unRAID share. I would imagine this share being tiny by default, say 1MB if machine has say more than 256MB of RAM, but configurable via the GUI (with some sanity limits).

 

There are a myriad of uses for a volatile small file system and i suspect the "build it and they will come" mentality will win out here.

 

Just for clarity I am not asking for this as a user mod or hack.

Uhhhh... you already have it.... the initramfs is a ramdisk mounted on /

Not so much. There is no default unRAID share that is a RAMDISK. Even if there was you can't set limits on it via the GUI.

There is no default unRAID share that is a RAMDISK

 

I just add a share for / called "root" to the samba config, so "//tower/root" gets me there.  It's handy for filling up most of available RAM in order to do benchmarking and know there will be very little RAM for buffers.

 

I also put a symlink in the root of each data drive to get to /

Yup that makes sense and there a good few other things that could be done relatively easily along these lines.

 

The main thing is that I make this request as a formal unRAID feature with GUI control and Limetech support. Everything is possible roll your own but that's not what this particular forum is about.

 

The fact you do this and I do something similar just adds weight that it could be an interesting feature for others/all.

I do it the same way like bubbaQ, and I fond it very convenient.

 

But if you want it to be separate from unRAID's buffers and stuff, and also to have a fixed limit, then:

mkdir /var/ramdisk
mount -t tmpfs none /var/ramdisk -o size=128m

...and in smb-extra.conf:

[ramdisk_128MB]
 path = /var/ramdisk
 read only = No

 

I noticed one very weird thing when testing that...

Upon umount /var/ramdisk, the files I had copied to it didn't disappear! Not only did the disk share stay intact and accessible, but also the limit was gone: I was able to copy more files to that share, way over 128MB, and then copy all the stuff back and compare the checksums.  

What the heck is going on?

 

 

The amount of data you copies was so small, it all fit in the buffers.

The fact you do this and I do something similar just adds weight that it could be an interesting feature for others/all.

 

Point taken, but I'm not too sure anyone who is in one of the limited situations where such a thing would be useful who is also someone who knows that it would be useful in that situation, would not also be someone who knows how to do it themselves rather easily.

The amount of data you copies was so small, it all fit in the buffers.

 

What do you mean?

 

Normally, when I umount a drive, its files stop being accessible.  Right? 

So what I described above is not normal behavior.  Am I missing something?

 

 

The amount of data you copies was so small, it all fit in the buffers.

 

What do you mean?

 

Normally, when I umount a drive, its files stop being accessible.  Right?  

So what I described above is not normal behavior.  Am I missing something?

 

Something else is wrong, it worked as expected for me.

 

root@Atlas ~ #mkdir /var/ramdisk

root@Atlas ~ #mount -t tmpfs none /var/ramdisk -o size=128m

root@Atlas ~ #df

Filesystem           1K-blocks      Used Available Use% Mounted on

none                    131072         0    131072   0% /var/ramdisk

root@Atlas ~ #cd /var/ramdisk

root@Atlas /var/ramdisk #touch x.x

root@Atlas /var/ramdisk #ls -l

total 0

-rw-r--r-- 1 root root 0 Jan 27 09:47 x.x

root@Atlas /var/ramdisk #cd /

root@Atlas / #umount /var/ramdisk

root@Atlas / #ls -l /var/ramdisk

total 0

root@Atlas / #

root@Atlas / #cd /var/ramdisk

root@Atlas /var/ramdisk #ls -l

total 0

 

Uhhhh... you already have it.... the initramfs is a ramdisk mounted on /

 

The difference with initramfs and a tmpfs ramdisk is tmpfs has a limit and if you have swap available, tmpfs can be swapped out.

 

Might be of some use as a ram based array cache, but for the normal unRAID user, i'm not sure of the extra work putting this into the unRAID distro is worth it.

 

@NAS, what's the impetus behind having it put in unRAID rather then some add on?

 

 

Normally, when I umount a drive, its files stop being accessible.  Right?  

So what I described above is not normal behavior.  Am I missing something?

Something else is wrong, it worked as expected for me.

I was referring to Samba. It kept working "normally" even after the umount.

And it didn't even have limit after the umount.

 

 

Normally, when I umount a drive, its files stop being accessible.  Right?  

So what I described above is not normal behavior.  Am I missing something?

Something else is wrong, it worked as expected for me.

I was referring to Samba. It kept working "normally" even after the umount.

And it didn't even have limit after the umount.

 

Samba would keep working after the umount as the underlying mount and initramfs would still be there.

The initramfs does not have a limit, therefore you could use all available ram until the system crashes. (and it will. ;-( )

It's really not a safe way to do it.  Also, the initramfs will not swap out unused memory chunks if you have swap space mounted.

 

What I've done to have a ramdisk and export the disks in one share was to mount a tmpfs on /mnt before emhttp was started.

Then export the /mnt mount point

But Weebo, I did just that! I exported a mount point of tmpfs!

And Samba was working just as expected, with limit and all... Until I did umount: then it wasn't as expected.

 

 

@NAS, what's the impetus behind having it put in unRAID rather then some add on?

 

Once unRAID ships with a modular system that means you can addon stuff without adding on stuff in the first place to make it work... and there are some official lines of peer review for officially supported plugins and hooks then things will change. Until then I am not a fan of the user hack for the general masses as the Limetech support structure is not there to make it fully reliable. Obviously people will disagree with some if not all of this but i feel strongly that whilst this is Linux and virtually anything is possible the official route is the way forward for the masses.

 

I reserve the right to completely change my opinion once the new plugin structure is officially in place

 

Or put another way... forget all that.... its a cool feature for unRAID to list it has

@NAS, I was more curious on why unRAID would need the ram disk or how it would be useful to a user?

Did you have a use in mind that would appeal to the masses?

 

@Purko. Perhaps I am dense.

If you mount a tmpfs on a place where samba can see it. Then write to the location, limits will be there according to destination.

if you umount that tmpfs and samba can still see it, it will write to the underlying filesystem, which in this case is initramfs.  Initramfs does not have size limits. It uses all available ram until it runs out.

If this were on a hard disk, the same behavior would occur.

@NAS, I was more curious on why unRAID would need the ram disk or how it would be useful to a user?

Did you have a use in mind that would appeal to the masses?

 

@Purko. Perhaps I am dense.

If you mount a tmpfs on a place where samba can see it. Then write to the location, limits will be there according to destination.

if you umount that tmpfs and samba can still see it, it will write to the underlying filesystem, which in this case is initramfs.  Initramfs does not have size limits. It uses all available ram until it runs out.

If this were on a hard disk, the same behavior would occur.

There is only one place I can think of where a smaller size-limited ramdisk is useful, and that is for log files.

 

They can then grow to the limit of the tmpfs, and never crash the server because you run out of space.  I made that suggestion to Tom almost a year ago here: http://lime-technology.com/forum/index.php?topic=3352.msg29874#msg29874

 

Although Tom can typically predict the size of the syslog, it quickly fills when errors occur on some systems.  Before he fixed log rotation, this was a huge issue.  Now, with log file rotation working, he probably forgot all about putting /var/log in its own tmpfs file system.

 

Joe L.

If you mount a tmpfs on a place where samba can see it. Then write to the location, limits will be there according to destination.

if you umount that tmpfs and samba can still see it, it will write to the underlying filesystem, which in this case is initramfs.

 

But of course!  What was I thinking?

I feel so stupid right now!   

 

 

@NAS, I was more curious on why unRAID would need the ram disk or how it would be useful to a user?

Did you have a use in mind that would appeal to the masses?

 

I can see users dumping sensitive data there that can be wiped securely and instantly since its never been on disk or as a sandpit for stuff that really can be deleted without care.

I can see users dumping sensitive data there that can be wiped securely and instantly

 

I already do that, but locally, not on the server, since the server is up 7x24x365... the sensitive stuff might not go away for a LONG time.

 

I use VSuite Ramdisk and couldn't be more happy with it.

 

  http://www.romexsoftware.com/

 

Under XP, it will use the memory above 3.25GB that XP can't see, and will do non-volatile RAMdisks too, by saving them to disk at shutdown and restoring them at startup.

 

I use one volatile RAMdisk for temp, and another that is non-volatile, for my XP profile and certain apps.

 

The RAMdisk is an order of magnitude faster than SSD.  You have not seen apps fly under XP till you have your profile, registry, and apps on a RAMdisk.

I use VSuite Ramdisk and couldn't be more happy with it.

 

   http://www.romexsoftware.com/

 

Under XP, it will use the memory above 3.25GB that XP can't see

 

Cool!  I was using some Ramdisk which is twice as expensive than what you linked,

and which lacks Hibernation support when disks are placed above 3.25GB.

Thanks for the link!