4 ms·

Disks have improved in I/O and write speed metrics substantially to the point where windows will literally index your file system so you can search faster, and

Disks have improved in I/O and write speed metrics substantially to the point where windows will literally index your file system so you can search faster, and antivirus will scan files in the background before you open them. I don’t think maintaining size state on directories would be all that much of a challenge.

Someone 2y ago
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)

Someone 2y ago

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)