Beaglebone Black filesystem resize - incorrect information? "just delete the partition and make a new one"

I am working remotely with a beaglebone black system.

I found this information on youtube about expanding the root filesystem.

https://www.youtube.com/watch?v=FK6wfV_19ac (watch from 12:50)

The author of the video demonstrates resizing of the filesystem by literally deleting the filesystem which contains /, and then creating a new partition.

(Unless I've completely misunderstood?)

This seems completely crazy. I can't understand how this worked and didn't destroy the filesystem? It seems like a complete fluke that no data was damaged in this process and that all the inodes are still valid.

This makes me wonder if I completely misunderstood something - and so I am now worried that this is actually a valid thing to do.

I would like a second opinion on this - is what the author instructs in the video the correct way to expand a filesystem? If so, why did deleting the partition containing all of the data of the root of the filesystem not destroy that data?

Partitions and filesystems are not the same. At no point the filesystem was destroyed.

Partition is just a part of a larger device identified by some entry in the partition table. fdisk manipulates this table. In DOS (MBR) partitioning scheme partition table is at (strictly: near) the beginning of the disk. In GPT it's near the beginning and (another one, backup) near the end. It doesn't belong to any partition, at least it shouldn't. In some sense you can think of it as "a table of contents".

Filesystem is a structure that usually lives inside a partition (but it may live in a regular file or take the entire device). Even if the partition entry is no more, you can mount the filesystem if you know its offset.

The author of the video destroyed the partition entry and created a new one. This only affected the partition table, not the actual data within the (old or new) partition, i.e. the filesystem. The partition in question was recreated larger but its starting sector remained. This is where the filesystem starts.

After the reboot the filesystem mounts successfully, because the kernel looks for its header at the beginning of the new partition, which is the same as the beginning of the old partition where the actual filesystem header was/is. The filesystem knows its size, so the fact the partition is now of a different size is irrelevant, as long as the filesystem "fits" (so enlarging is always OK; see the note about shrinking at the end).

Finally resize2fs was used to actually resize the filesystem. The new size was not specified, so the tool let the filesystem take the entire partition. This was the only moment anything was done to the filesystem itself (aside routine mounting and accessing). The tool supports resizing to the right (i.e. without moving the beginning of the filesystem) even if the filesystem is mounted. This is what happened.

Yes, it is the correct way.

Note if you want to shrink a partition, you should shrink the filesystem first, only then adjust the partition table. The rule is at any moment the whole filesystem should fit in the partition. Shrinking a mounted filesystem may not be as easy (or possible at all) as expanding it.