Copying files from eMMC to SSD and vice versa

I have flashed eMMC of the devkit using script. After booting the devkit, df -h command output is as follows.

nvidia@tegra-ubuntu:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 57G 7.8G 46G 15% /
none 15G 0 15G 0% /dev
tmpfs 15G 0 15G 0% /dev/shm
tmpfs 3.0G 11M 3.0G 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 15G 0 15G 0% /sys/fs/cgroup
tmpfs 3.0G 16K 3.0G 1% /run/user/112
tmpfs 3.0G 8.0K 3.0G 1% /run/user/1000

I think the df -h output is related to eMMC. Because the following is the output of /proc/partitions.

179 0 62160896 mmcblk0
179 1 60635136 mmcblk0p1
179 2 131072 mmcblk0p2
179 3 768 mmcblk0p3
179 4 32384 mmcblk0p4
179 5 131072 mmcblk0p5
179 6 768 mmcblk0p6
179 7 32384 mmcblk0p7
179 8 81920 mmcblk0p8
179 9 512 mmcblk0p9
179 10 65536 mmcblk0p10
179 11 81920 mmcblk0p11
179 12 512 mmcblk0p12
179 13 65536 mmcblk0p13
179 14 409600 mmcblk0p14
179 15 491008 mmcblk0p15
7 0 16384 loop0
251 0 1957932 zram0
251 1 1957932 zram1
251 2 1957932 zram2
251 3 1957932 zram3
251 4 1957932 zram4
251 5 1957932 zram5
251 6 1957932 zram6
251 7 1957932 zram7

Can you guide me to copy a file from eMMC to SSD and vice versa. How I can access the SSD?

You might add more information about how the copy is to be used since this changes the “best” method.

/dev/mmcblk0p1” is the root filesystem. Unless something changes, this is the content on “/”, but other filesystem types are mounted to different subdirectories (such as “/sys”) which are not actually on the eMMC (or any disk). There is a concept sometimes used during different types of copy known as “do not cross filesystems”.

If you blindly copy “/”, then filesystems will be crossed, and you would get the temp content as well, which you don’t want. A command like rsync will do a much better job and can understand things like device special files, symbolic links, so on. The dd command could directly read and write a bit-for-bit exact copy of the rootfs by dd of /dev/mmcblk0p1 to a partition of the SSD, but there would be other steps…and this command isn’t normally used on a filesystem which is currently in use for write. Thus the choices depend on what you wish to accomplish and under what circumstances.

Incidentally, the rootfs can be cloned from a Jetson which is in recovery mode. This is much like dd, but the rootfs is not being written to so the result is better than those unpredictable issues of using dd on a mounted filesystem.

The basic thing which I am checking here is, what is the device node for the ssd under /dev/?

For eMMC the device node is


and the corresponding eMMC partitions are

/dev/mmcblk0p13 /dev/mmcblk0p4 /dev/mmcblk0p9
/dev/mmcblk0p1 /dev/mmcblk0p14 /dev/mmcblk0p5 /dev/mmcblk0rpmb
/dev/mmcblk0p10 /dev/mmcblk0p15 /dev/mmcblk0p6
/dev/mmcblk0p11 /dev/mmcblk0p2 /dev/mmcblk0p7
/dev/mmcblk0p12 /dev/mmcblk0p3 /dev/mmcblk0p8

Similarly I am looking for SSD device node, so that I can create required partitions on it.

Device node naming is determined by the driver (and sometimes modified by udev). I don’t have an SSD, but it could be either one of the “/dev/sda#” or a “/dev/nvme0n#” naming convention. It depends on the format. What do you see from:
lsblk -f

Sorry, SSD is not available on the devkit. There was WiFi and Bluetooth module connected to M.2 Key E socket. Initially I misunderstood that it is a SSD card, after taking snap of the devkit and zooming it came to know that it is a WiFi and Bluetooth module.

An alternative is to get an external USB drive enclosure. Some are for ordinary SATA drives, others are for SSD or NVMe.