3 ms·

I expect performance would suffer quite a lot. In a system with high I/O, there would be a lot of contention on updating the size of such directories as /home o

I expect performance would suffer quite a lot. In a system with high I/O, there would be a lot of contention on updating the size of such directories as /home or /tmp, let alone /. Also, are you going to update a file’s size for every write (could easily be a thousand times if you’re copying over a 10MB file) or are you going to coalesce updates to file sizes? If the latter, how do you recover after a crash? Virtual directories such as /dev and /proc would require special-casing. Mounting and unmounting disks probably would require special-casing.

hsbauauvhabzb 2y ago
Haven’t many similar issues been solved in journaled file systems and/or things like database transaction logs and indexes? Real-time high precision accuracy is not required, knowing how big a directory is, is a frequent use case of directories. Hell, ‘df’ tracks this at the partition level, including edge cases, as does ‘du’
- Someone 2y ago
  As far as I am aware, neither of those cascade sizes up. Also, doing that in databases isn’t a solved problem. count(*) can be slow in databases. See for example - PostgreSQL: https://dba.stackexchange.com/questions/314371/count-queries-are-too-slow-even-with-an-index-only-scan https://dba.stackexchange.com/questions/314371/count-queries..., https://wiki.postgresql.org/wiki/Count_estimate https://wiki.postgresql.org/wiki/Count_estimate - Oracle: https://forums.oracle.com/ords/apexds/post/select-count-very-slow-9199 https://forums.oracle.com/ords/apexds/post/select-count-very... (Both databases use MVCC (https://en.wikipedia.org/wiki/Multiversion_concurrency_control https://en.wikipedia.org/wiki/Multiversion_concurrency_contr...) to ensure that concurrent queries all see the database in a consistent state. That makes it necessary to visit each row and check their time stamp when counting rows)

hsbauauvhabzb 2y ago

Haven’t many similar issues been solved in journaled file systems and/or things like database transaction logs and indexes? Real-time high precision accuracy is not required, knowing how big a directory is, is a frequent use case of directories. Hell, ‘df’ tracks this at the partition level, including edge cases, as does ‘du’

Someone 2y ago
As far as I am aware, neither of those cascade sizes up. Also, doing that in databases isn’t a solved problem. count(*) can be slow in databases. See for example - PostgreSQL: https://dba.stackexchange.com/questions/314371/count-queries-are-too-slow-even-with-an-index-only-scan https://dba.stackexchange.com/questions/314371/count-queries..., https://wiki.postgresql.org/wiki/Count_estimate https://wiki.postgresql.org/wiki/Count_estimate - Oracle: https://forums.oracle.com/ords/apexds/post/select-count-very-slow-9199 https://forums.oracle.com/ords/apexds/post/select-count-very... (Both databases use MVCC (https://en.wikipedia.org/wiki/Multiversion_concurrency_control https://en.wikipedia.org/wiki/Multiversion_concurrency_contr...) to ensure that concurrent queries all see the database in a consistent state. That makes it necessary to visit each row and check their time stamp when counting rows)