If you find the eMMC is too small for your application you can just add an SDHC card to the pool and instantly more storage will be available. No need to mount or move files around.
The factory partitioning based on ext4 (rootfs 1536MiB, boot 64MiB, update 704MiB, home the rest) made sense at the time.
The update partition was made large to be able to hold the OTA (over-the-air-update), while rootfs was 1GiB. However, at a certain point in time rootfs needed increasing as the expense of update, so OTA didn’t work any more. The result of course, 704MiB is not being used at all and the unused space in rootfs is still not available to home.
With btrfs we now have a single rootfs partition with subvolumes @, @boot, @home.
The free space is available to all subvolumes.
Btrfs can take a snapshot of a subvolume and keep that as a backup. Due to it being a COW file system the snapshot hardly takes up any space, only files that are modified are re-written to disk and take additional space.
This allows experimenting while quickly being able to fall back to the working subvolume and repair.
This also allows to take snapshot of the root (or other) image and use btrfs send to send it to the host as a backup.
With btrfs we can have a 2nd root image that we can boot. For this we have reserved the subvolume @new. This allows care free experimenting with for instance a new yocto release or debian image.
It is easy to send the @new subvolume OTA:
cat edison-image-edison.snapshot | ssh root@edison.local "btrfs receive /mnt"
or use the utils/flash/btrfsFlashOta.sh to do that smoothly.
Alternatively, you can receive a subvolume from the host sent earlier as a backup.
This is not exactly unique to btrfs. In general /boot (@boot) can hold multiple kernels. But considering that we can have also multiple root images, we have moved the modules directory to @modules and make that mount on /lib/modules.
This way, you can install a @new image with a new kernel, and boot that with the old tried and tested kernel. Or you can boot the @ old image with the new kernel.
After updating using flashall btrfs filesystem resize max / can perform a resize on the mounted file system.
As btrfs has per file compression we can increase available disk space, especially when there are many text or other easily compressible files on disk.
Compression can be done on the fly:
root@edison:~# mount | grep btrfs
/dev/mmcblk0p8 on / type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=256,subvol=/@)
/dev/mmcblk0p8 on /boot type btrfs (rw,noatime,compress=lzo,ssd,space_cache,subvolid=257,subvol=/@boot)
/dev/mmcblk0p8 on /lib/modules type btrfs (rw,noatime,compress=lzo,ssd,space_cache,subvolid=258,subvol=/@modules)
/dev/mmcblk0p8 on /home type btrfs (rw,noatime,compress=lzo,ssd,space_cache,subvolid=261,subvol=/@home,x-systemd.automount)
Or on demand:
root@edison:~# btrfs filesystem defrag -r /
root@edison:~# btrfs fi us /
Overall:
Device size: 3.55GiB
Device allocated: 1.22GiB
Device unallocated: 2.33GiB
Device missing: 0.00B
Used: 753.66MiB
Free (estimated): 2.71GiB (min: 1.54GiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 2.54MiB (used: 16.00KiB)
Data,single: Size:1.02GiB, Used:657.73MiB
/dev/mmcblk0p8 1.02GiB
Metadata,DUP: Size:93.44MiB, Used:47.95MiB
/dev/mmcblk0p8 186.88MiB
System,DUP: Size:8.00MiB, Used:12.00KiB
/dev/mmcblk0p8 16.00MiB
Unallocated:
/dev/mmcblk0p8 2.33GiB
A more accurate analysis of compression results can be done using btrfs-compsize:
root@edison:~# /usr/bin/compsize /bin /boot /etc /home /lib /opt/ sbit /sketch/ /usr/ /var/
Processed 26316 files, 9056 regular extents (10118 refs), 17382 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 92% 680M 737M 764M
none 100% 632M 632M 650M
lzo 45% 48M 105M 113M
You can take your existing Edison with ext4 partitions and convert to btrfs without loosing your data. You can even undo this and go back to ext4. Of course some modification to the image are needed which you can do manually.
In principle you can do this without backing up your current installation.
There may be other file systems that can do what btrfs can do, zfs comes to mind. However, btrfs support is in the vanilla kernel as well as in U-Boot. Turning on support is just a matter of flipping on the switch.
As we have the kernel on @boot when the file system get’s corrupted we might not be able to boot the kernel and if we could might not be able to repair it because then it is already mounted.
To resolve this, we create a separate rescue image that has it own kernel and root image in a initrd. The initrd hold all the tools needed to convert an ext4 partition to btrfs or to repair damaged file systems.
© 2018 Ferry Toth