Description of pfrd in the docs

[foux]

Hi there!
I've got a question regarding the description of pfrd here. It reads :

Selects a branch randomly, with the probability of selection proportional to its available space relative to the total available space across all branches. For instance, if Branch A has 100 GB free and Branch B has 50 GB free, Branch A is twice as likely to be chosen.

I'm baffled by the end. If the calculation is based on pourcentage used, is the if Branch A has 100 GB free and Branch B has 50 GB free, Branch A is twice as likely to be chosen really correct? For example if branch A and branch B aren't the same size?

Isn't it if branch A has 50% free and Branch B has 25% free, Branch A is twice as likely to be chosen ? Or am I just not understanding pfrd right?

Thanks for your answers!

[trapexit]

No, it works exactly as it is described. The percentage is based on the free space in bytes. Not the percentage of the filesystem. It makes little sense to do based on percent of the filesystem. A 2byte filesystem with 1 used is 50% filled. But a 100TB filesystem with 90TB used is only 10% free.

[trapexit]

That doesn't materially impact average usage. And is access pattern based.

[foux]

Sorry but it really does. The performances at the end of the FS are 30 to 50% less than at the start of the FS. You have for exemple a study here : https://www.usenix.org/legacy/publications/library/proceedings/ana97/full_papers/vanmeter/vanmeter/zcav.html

[trapexit]

You do realize 1) that's 30 years old? 2) Filesystems and operating systems are a lot more complicated than what that portrays? Nothing is so simple as comparing angular velocity. Filesystems are not writing out singular tracks of data. Blocks are logical and not physical to the OS. The OS queues up requests at the IO layer depending on what the storage and interconnect offer. Files become fragmented. Layouts change and fragment. Pointing out that one part of the physical device is faster than another at such a low level is totally missing the the bigger picture.

Device contention, interconnect contention, etc have a far more significant impact. Disrupting linear reading with any random access entirely destroys performance. Can be orders of magnitude slower. The perf differences between inner and outer rings, assuming no logical block movements and entirely contiguous reads, is nothing close to that. And you do not get to control those accesses.

Besides... the physical size of these devices are mostly the same. The density increases over time. So a 1TB drive 50% full and a 10TB drive 50% full are still 50% filled unless using odd platter usage. And so 5TB vs 500GB would be the pfrd comparison. Meaning 10TB filesystem is 20 times more likely to be selected. And any speed decrease due to that concern would be impacted significantly less vs a smaller capacity device.

[foux]

I totally agree with you that FS are way more efficient today that they were 30 years ago. But the physics problems is still the same. I'm mostly familiar with BTRFS as it's my FS of choice (I know, it has a lot of drawbacks, but I just love it ;) ). BTRFS will always try to write its data chunks at the begginning of the drive especially to have the better performances. If a chunk at the beginning of the disk gets free, BTRFS will try to use it, provided it doesn't create too much fragmentation. SO yeah, after some time, and mostly because of COW, the data will be spread across most of the drive, but BTRFS will always try to allocate the chunk on the begging of the FS rather than at the end.

But I don't know very well the other FS, so I'll take your word for those!

[trapexit]

Even if they didn't try explicitly almost every filesystem ever that isn't designed specifically to some physical medium design (like f2fs) will fill in gaps from previously removed data. Hence why relying on size / percentage alone is not meaningful. There is a lot going on and you can't know where the filesystem will place data, if that data would fit, etc. You are micro optimizing.