For a typical user, hard links would be mostly employed by git for its internal structures, and it’s difficult to accumulate over 300 GB of git repos.
Sparse files would actually be more believable, since they’re used by both torrent clients and virtual machines.
sbeak@sopuli.xyz 10 hours ago
Using -H throws an error as symlinks aren’t supported in exFAT it seems.
SlurpingPus@lemmy.world 10 hours ago
By the way, do you have lots of torrents downloaded or large virtual machines installed? Both torrent clients and virtual machine managers use ‘sparse files’ to save space until you actually download the whole torrent or write a lot to the VM’s disk. Those files would be copied at full size to exFAT.
If you have folders with such content, you can use e.g. Double Commander to check the actual used size of those folders (with ctrl-L in Doublecmd). Idk which terminal utils might give you those numbers in place, but aforementioned
ncducan calculate them and present as a tree.sbeak@sopuli.xyz 10 hours ago
using du -hsc returns 384G with /home/sbird, and 150G inside the external SSD (when it does not have any of the files transferred with rsync)
SlurpingPus@lemmy.world 10 hours ago
Well, that’s not what I meant. If you have directories with torrents or VMs,
dumight report different size for those directories on the source and target disks. Then it might’ve meant that those are the culprits.With just the source disk, you can check
du -hsc dirnameversusdu -hsc --apparent-size dirnameto check if the disk space used is much smaller than the ‘apparent size’, which would mean there are sparse files in the directory, i.e. not fully written to disk. rsync would copy those files to full ‘apparent size’.As mentioned elsewhere, btrfs might also save space on the source disk by not writing duplicate files multiple times — but idk if
duwould report that, since it’s specific to btrfs internals.