The space of Jetson TX1 is not enough

hi
I just start to learn linux,and I’m running caffe with TX1,as you know,the caffemodel is very big,but the space of TX1 is not enough now,so what should I do to release the space?
thank you!

You should use another storage for your development projects, such as a USB or SATA disk, (or a SD card but it might be limited in usable size), and just install binaries (and runtime data if any) on the Jetson.

Additional note: Many of the extras installed for tool kits and APIs used by NVIDIA are placed on “/usr/local”. This is a great place to put the extra storage mentioned by @Honey_Patouceul. This example uses the SD card first partition is used (mmcblk1p1, but for a SATA device it might instead be “/dev/sda1”):

sudo -s
mkfs.ext4 /dev/mmcblk1p1
mount /dev/mmcblk1p1 /mnt
cp -adpR /usr/local/* /mnt
umount /mnt
# Optionally delete "/usr/local/*": "rm -Rf /usr/local/*" <b>once tested, PRIOR</b>
# to mounting mmcblk1p1 there...this saves space on the original device mmcblk0p1 rootfs.
mount /dev/mmcblk1p1 /usr/local
exit

Note that you could put this mount point in “/etc/fstab” for automatic mount, but if the mount entry makes the device mandatory and it is a removable device, then not having the device present with a correct partition it might cause boot to fail. An fstab entry like this would let you just “sudo mount /usr/local” without remembering details:

/dev/mmcblk1p1   /usr/local   ext4   noauto,user,exec,owner,exec 0 0

@linuxdev@Honey_Patouceul,thank you very much,I will try it.

hi,linuxdev

I have done what you said,but while run “cp -adpR /usr/local/* /mnt”,the error appears,such as:

cp: failed to preserve ownership for '/mnt/cuda-8.0/doc/html/libdevice-users-guide/__nv_fadd_rn.html': Operation not permitted

and if the command works,could I delete the “/usr/local/*” without affecting the normal functioning of the TX1?

Did you use the “sudo -s” to drop into a root shell prior to running the commands? Root should be able to do this, other users cannot (only root can preserve permissions of another user).

yes,I used the “sudo -s” but also failed,I tried again,such as(I mounted the USB in /home/ubuntu/mnt):

root@tegra-ubuntu:~# cp -adpR /usr/local/cuda-8.0/* /home/ubuntu/mnt
cp: failed to preserve ownership for '/home/ubuntu/mnt/bin/cudafe++': Operation not permitted

What is the “ls -l” output for the file “cudafe++” on both the “mnt” version and the original “/usr/local” version?

Is the file system you have mounted a native Linux type? If you cd to where the cudafe++ is being copied to, what is the output of “df -H -T .”? If it isn’t formatted to a native Linux file system type, then the drive will be incapable of preserving permissions.

root@tegra-ubuntu:~/mnt# df -H -T .
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda1      vfat  7.6G  2.7G  5.0G  36% /home/ubuntu/mnt

is that wrong?if it’s wrong,how to format the USB to a native Linux file?

There you go…it is type VFAT. This is a windows style format, and it has no ability to understand or preserve Linux permissions. The flash would appear to work if you use this, but actual operation would not. So before you mount this it must be ext4. Technically, what you are doing might not need all permissions preserved, but it is asking for trouble. Before mounting try “sudo mkfs.ext4 /dev/sda1”.

oh,I understand,thank you!By the way,if I turn the USB into ext4 and copy “/usr/local/*” to it, then delete the “/usr/local/”, Will TX1 be affected?or it cannot works without the USB after copying and deleting?

“/usr/local” is not needed for booting up or normal operation. Whatever you put there will need it, e.g., CUDA programs would fail if you need this and it isn’t there.

There are two special cases though, and most people wouldn’t run into this first one, but might…that is if the default linker path for the system puts something in “/usr/local” into the linker by default during startup. The linker tells the system where to find libraries, and it is conceivable that if the system linker had a failure then boot would be an issue. You can know what the linker sees via “ldconfig -p”…if a file there has “/usr/local” in it, then the partition must be there for normal function. Example test:

ldconfig -p | egrep '[/]usr[/]local'

Another issue is if you set up for automount of the directory, and if the automount is marked as mandatory. The system will fail and stop when it can’t find the mount device…but as long as you do not make this mandatory it will work, and making it mandatory would have to be intentional.

One note about using a particular SD card or SATA drive partition for a specific mount point: You would probably be annoyed if plugging in the SD card caused it to be mounted automatically somewhere in “/media”, so you may want to put a rule in “/etc/fstab” to name the specific SD card and bind it to “/usr/local”…this can be done without causing automount. From that point on your user could mount the device with just “mount /usr/local” and the rest of the information would be in fstab and it would know that this particular SD card or SATA partition goes there.

You might find the output of “lsblk -f” interesting, as it points out both file system type and UUID. UUID is Universally Unique ID, and can be used to name a device for mounting. A UUID to identify a device for mount on “/usr/local” could override automount to “/media”. Options like “noauto” for an fstab entry can make automount of the device stop…combine the two and life is simplified. An example entry for the SD card might be something like this (I’m using an arbitrary UUID, it is nonsense, just use the actual UUID):

UUID=a1234567-a123-bcdef-1234-a123b123c123  /usr/local ext4  defaults,noauto  0 0

The above would allow “sudo mount /usr/local”…other options would allow a regular user to do the mount.

thank you very much,you help me a lot,not only solve my original question but also tell me some knowledge,thanks again!