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
home the rest) made sense at the time.
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
btrfs we now have a single
rootfs partition with subvolumes
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.
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 email@example.com "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
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
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 hold all the tools needed to convert an
ext4 partition to
btrfs or to repair damaged file systems.
© 2018 Ferry Toth