8

Is it possible to create an auto-growing tmpfs ramdisk on a rooted Android 4.x? If yes, how?

  • 2
    What do you need this for? – geffchang Jul 30 '13 at 5:14
  • temporary storage for various document files – eadmaster Jul 30 '13 at 5:36
  • 1
    SDCard is not auto-cleaned at stutdown... – eadmaster Mar 31 '14 at 5:00
  • 2
    @geffchang what difference does it matter why he needs this? i happen to need this too, for a totally different reason. – Michael Apr 5 '14 at 23:22
  • 3
    and in my case, the reason is for temporary storage (Android can kill my process without warning at almost any time) without needing to touch flash (limited erase cycles, increased power usage, slower, etc.) – Michael Apr 5 '14 at 23:50
6

If you do a cat /proc/filesystems you should notice tmpfs. So if you have access to the mount command, you shoud be able to

  1. create a directory (mkdir MYDIRECTORY)
  2. mount a tmpfs-filesystem there (mount -t tmpfs tmpfs MYDIRECTROY)

Per default a tmpfs-mount will use halv of the available RAM on your system. So rather than "auto-growing" you can think of it as "auto-shrinking" - i.e. the more you use it, the less RAM will be available. In the worst case your system might start swapping (which you do not want). You can use options to use a different RAM-size for that mount.

2017-02-28 Update: Due to the restrictions imposed by Android you should choose a mount point below an writeable to all Apps. Like an SD Card.

  • ok, this way is writable by all apps: mount -o size=16M -t tmpfs tmpfs /data/local/tmp – eadmaster Apr 3 '14 at 5:14
  • @eadmaster what part about that makes it writeable by all? the size or the mount point? (it's not working for me...) – Michael Apr 5 '14 at 23:43
  • @Michael what attributes do you see for . if you issue ls -Fal within the mounted directory? – Nils Apr 6 '14 at 20:08
  • ls -Fal in the mounted directory gives no output. I just get the prompt back. If I list the directory from the parent, I get drwxrwxrwt root root 2014-04-06 20:18 tmp – Michael Apr 7 '14 at 3:20
  • @Michael if your OS is rooted you should be able to access it – eadmaster Apr 7 '14 at 15:05
3

From the linky the OP has enclosed, the key part summed it up:

tmpfs is supported by the Linux kernel from version 2.4 and up.[3] tmpfs (previously known as shmfs) is based on the ramfs code used during bootup

Emphasis mine, that is what the RAMDisk is about! It enables the kernel to temporarily mount the root filesystem, and continue executing the necessary scripts upon start-up.

Same applies in this case of Android, each and every boot.img that is flashed to the /boot partition, whether by Odin, fastboot, Kies, Sony Update Software, Heimdall, etc, contains the "ramfs code", which has a directory structure containing, pertinent ones are included:

  • /dev for device files
  • /sbin for system binaries
  • /sys for usage of interacting with the device files after /proc has mounted

The boot-up script reads the ramfs directory structure and mounts it after successfully mounting the /system in the very early stage of boot.

As in relation to the OP's keyword in the question:

create an auto-growing ...

It does not auto-grow per se, rather, its limited by the ramfs structure, and amount of RAM available, and more importantly, it disappears on reboot!

The confusion comes from inter-mixing "RAMDisk" with "RAMDrive" interchangeably, technically a RAMDrive, is a swap space in the native swap partition, commonly found on desktop Linux If you're thinking of the old DOS era, where RAMDrive was used, to simulate a disk drive resident in memory, and programs when copied over to that disk, and loaded faster not execute faster, rather than loading from the old MFM/RLL disk-drives (Ever see DOS directory listing scroll very slowly on those drives?) this, was also known as RAMDisk as well! (To make matters worse, back then, different manufacturers produced RAMDRIVE.SYS or even RAMDISK.SYS!)

In the case of viewpoint of the Linux kernel, both desktop and Android, RAMDisk is tmpfs, but is not intended for normal users to store data/documents etc as that is exclusively for the usage by the kernel itself!

Edit

To note @nil's comment below, you can mount it yes, but it comes with a cost, resources allocated to the tmpfs gets halved and uses up half of remaining of whatever amount of RAM left. Realistically speaking, it is not an ideal avenue to persue from the viewpoint of Android running on devices.

That is where the /sdcard comes in, to store user data/documents for that reason alone, hence why I omitted the fact that you can, but then again, why?

  • What if the end user forgets to save the data to the right place - because that is lost upon reboot!
  • So the short answer is: Yes, you can. mount -t tmpfs. – Nils Jul 30 '13 at 14:21
  • @Nils I did not say yes! That is done from the moment the kernel has booted and executes mount -t tmpfs after reading the ramfs (which has a barebones init script), once that's mounted, then the rest of the system brings up as in post-boot, which is the Android environment. Also, by doing that afterwards, for example adb shell, you are reducing system resources, especially in the case of smartphones with limited memory and resource! – t0mm13b Jul 30 '13 at 15:15
  • 1
    No, mounting a tmpfs will not use RAM. Usage will start when you put files into it - at least this is what my Linux-servers do. And Android runs on Linux... – Nils Aug 7 '13 at 21:27
  • @Nils Very wrong impression. Android does not run on Linux! The kernel is linux, but userland space is not bash etc like full blown desktop counterpart. It uses bionic runtime library, no glibc and dalvik/zygote from there on upwards to Android home screen. – t0mm13b Aug 7 '13 at 21:33
  • tmpfs is kernel- not user space. So my guess is that this is not even a kernel-module, since this is needed during boot to mount the initrd. – Nils Apr 6 '14 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.