On Sun, Apr 05, 2020 at 08:47:15PM +0200, Goffredo Baroncelli wrote: > Currently BTRFS allocates the chunk on the basis of the free space. > > For my tests I have a smaller ssd (20GB) and a bigger hdd (230GB). > This means that the latter has higher priority for the allocation, > until the free space became equal. > > The rationale behind my patch is the following: > - is quite simple (even tough in 3 iteration I put two errors :-) ) > - BTRFS has already two kind of information to store: data and metadata. > The former is (a lot ) bigger, than the latter. Having two kind of storage, > one faster (and expensive) than the other, it is natural to put the metadata > in the faster one, and the data in the slower one. But why do you assume that SSD means fast? Even with traditional disks only, you can have a SATA-connected array for data and NVMe for metadata, legacy NVMe for data and NVMe Optane for metadata -- but the real fun starts if you put metadata on Optane pmem. There are many storage tiers, and your patch hard-codes the lowest one as the only determinator. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi ⠈⠳⣄⠀⠀⠀⠀
