Gfrktyl

When duplicating a file (copy-paste in OS, or in python), for example, an image, is all the raw data read from the SSD and passed via the CPU and then back to the SSD, or is only some metadata read to the CPU and the rest handled by the local SSD controller?
Are there SSDs capable of local copy-paste, i.e. file raw data not leaving the SSD?

For example, the following python code:

from shutil import copyfile



src = "src.JPG"

dst = "dst.JPG"

copyfile(src, dst)

I would like to reduce the energy consumption of data migration and make use of the high internal SSD bandwidth...

SSDs cannot do that - not, at least, with current firmware, and not with current OSs.

SSDs implement the same command set (with a few additions like TRIM) as traditional SATA hard drives. There is simply no command you can send the drive for "copy the contents of block x to block y".

There are commands for reading from the drive, i.e. copying the contents of specified blocks on the drive into system RAM. And there are commands for writing, i.e. copying from system RAM to specified blocks on the drive. And there are a LOT of other commands that are not read or write commands. But there are no "copy within the drive" commands.

So - the drive just doesn't "know" how to do that.

A "copy" command could be implemented in the drive firmware. But the job wouldn't be done there. The OS developers would have to modify the various OS's file system and disk drivers to support it, and would have to provide an API for it. And each OS's file management utilities would have to be modified to use it. But today, since no SSDs (or hard drives) implement an onboard "copy" command, the OSs don't have support for such a thing either.

I know you asked about files, but drives don't know anything about files. Or directories ("folders"), or even partitions for that matter. The OS's file system and other drivers implement all that stuff. The read and write commands sent to the drive always work in terms of block numbers. The OS file system driver knows which blocks make up each file. For this question, though, this doesn't matter. Drives don't implement any sort of "copy" function, whether in terms of blocks or in terms of files.

Btw, if you're curious about what is in the ATA command set, you can find a freely available and relatively recent version of the spec here.

In a word No. Filenames are a fairly high-level concept, and they abstract away a great many complexities making a hardware copy-paste impossible.

Your example code or using a file manager both require a filesystem to operate on which is a service provided by the operating system. A raw disk as the disk controller presents it, is just a collection of 1's and 0's. The Operating systems filesystem determines how the OS writes data to the disk, and maintains various data structures on the disk to describe it. The Operating System "decides" what data to return when an application opens and reads a given filename. When writing data, its the OS/filesystem that records physically where on the disk the binary data for a given filename is stored, with raw data often being split up to best use the available unused blocks of disk (aka fragmentation).

In terms of energy consumption, i dont think you will have a lot of control here beyond choosing efficient hardware (high PSU efficency and low wattage CPU/mobo). If you can operate on raw disks (ie clone the entire disk at a binary level - ie the filesystem and all its contents) you could use a hardware disk copier which would likely be quicker and much lower wattage (but probably not what your looking for).