I’m using a Jetson TX2 dev kit and it has only 2 GB space left (out of 32GB). Is there a way to increase the inbuilt storage (32GB) of the Jetson TX2 using an SD card (I have a Class 10 SD card)?
If yes, then how?
By far the simplest method is to just add a partition to the SD card and replace content on “/usr/local/” with that partition. Or in a similar manner, “/home”. The SD card can be partitioned any number of ways. It’s fairly trivial to clone “/home” or “/usr/local” to a partition on the SD card. If the card is removed, then the system just reverts back to the content the mount covers. Changes performed with the SD card mounted would revert until the SD card is added back. You cannot expect to add or remove the card while the system is in operation unless you first disable any user of those partitions so proper umount and mount can be performed, but at boot it is never an issue.
Alternatively, you can boot to the SD card as a new rootfs (I don’t know if performance would be bad or not). This is perhaps a bit more involved, but it also serves as a rescue disk in cases where only the rootfs partition is bad.
If you have two SD cards you could do both. If you have a large enough SD card, and can make the first partition the same as the current rootfs, and then add large partitions to the SD card for “/usr/local/” and “/home/”, then you could do a combination. You’d have to use serial console though to select SD card at boot if you choose both (which I can explain if you choose that route).
I tried the SD card route and it was painfully slow. I got an SATA SSD and it made a world of difference. I did as linuxdev suggests and mounted it to /var/lib/docker (where all my storage was being consumed)
acwatkins,
Could you please give some shell commands for how you remounted /var/lib/docker to your SATA SSD card? I am looking to do the same thing with the SD card. Thanks.
His SSD probably had a different partition and device name, but if you use “lsblk -f”, and if the partition of your SD card turns out to be “/dev/mmcblk1p1” (adjust for your case), then you could consider what follows as one option.
Assuming mmcblk1p1 is formatted as ext4:
sudo -s
mount /dev/mmcblk1p1 /mnt
cd /var/lib/docker
cp -adpR * /mnt
umount /mnt
cd
mount /dev/mmcblk1p1 /var/lib/docker
exit
That is of course only temporary, and leaves the old content in place if the SD card is not present. That would be a place to start to see how it works. After that you can do things like make a mount line in fstab which mounts that specific partition at that specific mount point if it is present. Should that also work, then you could free up space on eMMC by deleting the original content when the SD card is not present.
I ended up writing a script to do this after flash. I don’t care about the contents of the docker mount, as I can just rebuild/pull it again, so this just formats it. Also, it runs a docker system prune in order to make the underlying docker folder on the root filesystem take up less space. This is using lvm and assumes the logical volume/volume group is already created, so yours may vary.
Note, this is run with sudo.
#!/bin/bash
docker system prune -af
systemctl stop docker
mkfs.ext4 /dev/mapper/vg-docker
echo "/dev/mapper/vg-docker /var/lib/docker ext4 defaults 0 1" >> /etc/fstab
mount /var/lib/docker
chmod g+rwx /var/lib/docker
chgrp docker /var/lib/docker
systemctl start docker
I might worry that the echo is adding a copy of the fstab line each time it boots. You will want to verify that after two or more boots the fstab hasn’t grown by multiple copies of that echo line. If this is happening, then you could just add a grep test to see if the mount point is already listed before using the echo.
It is run once, not on boot. Yes a more sophisticated version could check for it, not a bad idea.
After quite a bit of fumbling, I was able to get to the desired solution.
Initially, I followed the steps outlined by linuxdev in #5. I built my docker images and all of the metadata was correctly stored on the sd card. As previously mentioned, this was a temporary fix.
For the permanent solution, I followed steps here. For me, the gnome-disks option was most effective and safest.
Thanks @linuxdev and @acwatkins!