RetroG

USB so-called DAS/JBOD/etc units usually internally use a SATA Port multiplier setup, and is likely the source of your issues. A SATA Port multiplier is a way of connecting multiple SATA Devices to one root port, and due to the way that the ATA Protocol works, when I/O is performed it essentially takes the entire bus that is created from that root port hostage until the requested data is returned. it also is important to know that write caching will skew any write benchmarks results if the enclosure uses UASP or you have explicitly enabled it. these devices perform even worse with a striping filesystem (like raidz, btrfs raid 5/6 or mdraid 5/6), and having highly fragmented data (which will cause a bunch of seek commands that again, will hold the bus hostage until they complete, which with spinning media does create a substantial I/O burden) honestly, your options are either accept the loss of performance (it is tolerable but noticeable on a 4 drive unit, no idea how it is on your 8 drive unit), or invest in something like a SAS JBOD which will actually have sane real world performance. USB isn't meant for more than a disk or two, and between things like this and hidden overhead (like the 8/10b modulation, root port and chip bottlenecks, general inability to pass SMART and other data, USB disconnects, and other issues that aren't worth getting into) it may be worth just using a more capable solution

you could make two partitions, one 16TB partition and an additional 380GB partition. And add both of those to the pool, but yes anything beyond 16TB exactly, will not allow 4k cluster size. and 4k cluster size is required for compression.

on an MBR Partition table, the limit comes from the ability to create offsets beyond 2.2TB. anything beyond that is a sort of no-mans-land that you can't do anything with. (excluding nasty hacks like hybrid gpt/mbr) Which is why I gave the advice of saving some money and getting a 2TB or 3TB disk. short of migrating your system to a version of windows that supports uefi (if your hardware supports uefi boot) there really isn't an alternative to use that much space on a boot disk unfortunately. the advice to match HDDs tends to be for RAID or RAID Style solutions (zfs raidz) where the disks are accessed in parallel, having the same disk geometry means you aren't being slowed down by this (some parts of the disk may be faster than others, and this varies between models of disks). it doesn't really apply to drivepool as it just places files on a filesystem.

this to me sounds like what happens when a 512 sector disk is presented or converted (without reformatting/re-partitioning) to 4k sectors. there are quite a few external chipsets that do this as this is a quick and dirty hack to get past the 2.2TB limit on MBR disks, which let's you use a full capacity drive on XP 32 bit where you otherwise couldn't (the other dirty hack is using no partition table, just ntfs at the start and end of the drive). you need to use the matching enclosure or the partition table won't make sense. or expect to re-partition it. you would probably have to internalize the bridge board or temporarily remove it from the pool, repartition, re-add. you may or may not need to use diskpart's clean command to re-partition if you can't via the GUI. (I am unaware of any way to access this kind of mismatched geometry in software on drives you can't convert to 4kn directly (via the HUGO or Seachest lite tools, it's worth trying these utilities (if your sata controller is at least 5 years old or newer) to see if they list 4k as possible on your drive however I haven't seen any 512e drive below 8TB that is convertible)).

you should have no problem doing that. however with the MBR partition limit it will limit you to a maximum partition size of 2.2TB on your boot drive. the rest will be "free space" in Disk Management. you are better off getting a 2TB drive (which will have no waste) or 3TB (only wasting ~600GB after TiB to TB accounting) realistically though all that Drivepool cares about is that they are the same filesystem, (IE NTFS vs ReFS) cluster size, 4kn vs 512e, and MBR vs GPT. even multiple partitions on the same disk, all don't matter to Drivepool as those are a few layers below it.

I've noticed this behavior with sparsely allocated files. what files are you storing on this pool? most (nearly all) BT clients use sparse allocation for instance. the "used" space doesn't seem to account for that and reports the space allocated and not the space used. as these sparse files are written out though the reported space will normalize out.