Creating own Data Partition

      Creating own Data Partition


      I would like to split some space from the rootfs to make another partition. The goal what I would like to achieve is that I can move all dynamic files of our application (for example the changeable configuration) to this partition. So normally I would mount this read-only too, but when I have to write stuff to it, I of course have to remount it writeable. But then, when accidently the power goes off, the rootfs would not be damaged, only the config-partition.

      Is that possible?
      Of course you can do this. Currently we have an MTD partition called "TargetFS" that is used as an UBI (Unsorted Block Image). Within this UBI, we have one volume called "rootfs" that uses the whole UBI. An UBI volume is more or less a kind of partition within an UBI. Of course you can have more than one volume in an UBI. Therefore the easiest way to implement your requiremens is to reduce the size of the "rootfs" volume and add another volume, for example called "data". Then you can still use "rootfs" fully read-only, mount "data" read-only for most of the time and remount it to read-write for the short periods of time when writing is required and then back to read-only.

      When defining volumes in an UBI, usually the maximum size for the volume must be given. Only on the last volume that you create, you can leave out the size. Which means this volume occupies all remaining free space in the UBI. This is what we do in our "rootfs" case. We simply leave out the size, which means the "rootfs" volume takes all available space. However if you want more than one volume, you have to determine the size for all volumes but the last.

      Let's assume you want to have 10MB space for the "data" volume. Then simply issue the following commands in U-Boot:

      Source Code

      1. ubi part TargetFS
      2. ubi remove rootfs
      3. ubi create data a00000
      4. ubi create rootfs

      This removes the existing "rootfs" volume, creates a new 10 MB "data" volume and then again adds the "rootfs" volume with the remaining free space. So now "rootfs" is smaller than before. Please note that the previous content of the old "rootfs" volume is lost when doing this, so please backup any important data first. The new volumes are completely empty then. So for example to install a root filesystem image again, use these commands:

      Source Code

      1. tftp rootfs_std-fsimx6.ubifs
      2. ubi write $loadaddr rootfs $filesize

      A completely different option would be to reduce the size of MTD partition "TargetFS" and add another MTD partition, possibly again with an UBI in it. But there is a big advantage of using all volumes in one UBI: wear leveling. If you use different MTDs, then only the memory blocks of one MTD will take part in the wear leveling of the UBI volume in that MTD. But if you have several volumes in a large UBI, then all memory blocks of the whole UBI will take part in the wear leveling of all volumes in it.

      Lets show this on two examples. We assume a flash with 250MB free space.

      Example 1: two MTD partitions: (a) 10MB "DATA" with UBI in it and one volume "data", (b) 240MB "TargetFS" with UBI in it and one volume "rootfs".

      The "data" volume is where you write to. So only the memory blocks of the "DATA" MTD can be used for wear leveling when you write your data. When you are writing heavily, then they will be worn after a rather short period of time. On the other side all memory blocks of "TargetFS" are still completely unused and fresh at ths time. So thy system will fail despite the fact that large regions of the flash memory are still fully operable.

      Example 2: one big MTD partition "TargetFS" with UBI in it with two volumes: (a) 10MB "data" and (b) 240MB "rootfs"

      Now all blocks of the TargetFS MTD are used for wear leveling. This means UBI even moves read-only data to different blocks from time to time so that in the end all memory blocks can be used for writing. This will extend the time to failure to 24 times compared to Example 1. And when the system now fails, the flash is really totally worn out.

      This is why we prefer one large UBI with several volumes over several UBIs wirh only one volume each.

      Your F&S Support Team
      F&S Elektronik Systeme GmbH
      As this is an international forum, please try to post in English.
      Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.


      Thank you so far.
      I successfully created the data partition (inside the TargetFS).
      Also i can mount it after boot. (mount -t ubifs /dev/ubi0_0 /tmp/data/)
      But how can i mount it automatically on boot? If i edit the /etc/fstab it doesn't make any difference.
      Maybe i have to put it into the bootargs in U-Boot?

      Can you give me an advice please?

      Thanks in advance.

      edit: I added mount as a script in /etc/init.d, but that doesn't seem to be the best solution.

      Post was edited 1 time, last by “cmilling” ().