Data (large files and granular small files) are stored on a filesystem in ‘fragments’ and are evenly distributed across, say, an ext4 partition. If the SSD root partition is 1 TB (for example) with 125 GB worth of data and then at a later date, I decide to dual boot another operating system, then on bootable live media I can perform a resize operation to create a new partition to make room for the new operating system. Before going ahead, for sure I will back up all my valuables (though there aren’t very many in my case on root because my high value data exists in my home directory which is on a different mount point - - with all the ultra valuable data being mirrored to Dropbox as well). So I have those bases covered. But my questions are: Even with my root partition backed up in a safe place, how high risk is a resize operation? Is Linux smart enough (and trustworthy enough) to consolidate all the currently evenly spread out data across the current SSD (ext4) root to make room for a new separate ext4 partition for a different operating system?
Yes, it certainly is.
resizing is not like the the disk is divided into more sections and everything that is now outside the previous sections is lost - that is what I read was your concern
use gparted from a live system and you should be good
If that wouldn’t be the case, then no server would use ext4. It works if you use it correct. Online moving/shrinking is another case, since ext4 is limited here to offline operations. Therefore LVM was born, BTRFS supports is out of the box (shrink/grow).
Unlike in the abomination known as Microsoft Windows, the Linux kernel actively works to counter fragmentation before it has a chance to occur by intelligently allocation file extents. Therefore, your data will mostly be packed together from the start of the filesystem, with only enough space between the main directories based upon the Orlov block allocator — btrfs handles things slightly differently due to the copy-on-write principle and the fact that btrfs has built-in volume management.
Conversely, Windows writes so-called unmovable files to the end of the filesystem, making it harder to resize, although their own partition resizing software does of course handle those files, provided that Windows is started in maintenance mode — or “safe mode”, or whatever it’s called.
There are edge cases in which you can still lose data!
A colleague of mine shrinked an ext4 volume. After that, there were some files that were corrupted.
What had happened ?
The file system was generated by a kernel with a special extension. However, the downsizing was carried out with a different kernel without this extension. After that, parts of individual files were outside of the ext-partition 
because the kernel used could not move them.
- Unfortunately, there was no suitable error message
- Luckily my colleague had a backup and was able to repeat the process until he understood the problem.
Touching populated partitions always runs the risk of corrupting data.
That said … with SSD or NVME if you follow these steps you can drastically minimize the likelihood
(though it still depends on manufacturer, firmware, etc)
I will describe this visually,as if one were using gparted - though the same principle would apply if using sector numerals or similar.
When making space for a new partition (shrinking existing ones) then make sure shrink from right to left and to then utilize the whole of the new space for new partitioning or move partitions to the far left before increasing the size of partitions (grow existing ones) by growing from left to right.
This helps ensure that the start sectors and subsequent data is properly aligned.
Example:
| Label | Mount | Size |
|---|---|---|
| PartA | /efi | 500 MB |
| PartB | Win | 120 GB |
| PartC | / | 100 GB |
So lets say we want to switch 20 gb from Win to / .
First shrink windoze (in the case of windoze use its own tools!)
| Label | Mount | Size |
|---|---|---|
| PartA | /efi | 500 MB |
| PartB | Win | 100 GB |
| New | BLANK | 20 GB |
| PartC | / | 100 GB |
Then reboot into something with gparted that isnt your root.
Then you will want to move PartC all the way left
| Label | Mount | Size |
|---|---|---|
| PartA | /efi | 500 MB |
| PartB | Win | 100 GB |
| PartC | / | 100 GB |
| New | BLANK | 20 GB |
Before growing it to the right.
| Label | Mount | Size |
|---|---|---|
| PartA | /efi | 500 MB |
| PartB | Win | 100 GB |
| PartC | / | 120 GB |
A warning again though: this is still not 100% safe. Keep backups if you would miss anything.