3 ms·

No. There is not 60TB of data on the disk, which is what the GUI is reporting in the article. The GUI doesn't say that 60TB of data would exist if the snapshots

by tumult 3y ago

No. There is not 60TB of data on the disk, which is what the GUI is reporting in the article. The GUI doesn't say that 60TB of data would exist if the snapshots were each individually flattened and expanded to another filesystem. It says there is 60TB of data filling the disk.

bayindirh 3y ago
However, the code traverses that amount of data. It doesn't matter if you pass over the same inode n times. From OS point of view, there's no difference. Of course you can write a more complicated calculation algorithm, but it'll require tons of syscalls to determine the type of the file handle you're interacting with and will be probably very slow. This is what rustup did inadvertently back in the day, and it caused NTFS to melt down to a halt because of stat() overhead [0]. [0]: https://www.youtube.com/watch?v=qbKGw8MQ0i8 https://www.youtube.com/watch?v=qbKGw8MQ0i8
- tumult 3y ago
  Why does the user care about how many times an iterator passes over an inode? The Finder is reporting incorrect information to them and may lead them to make bad decisions, like buying unnecessary external storage drives. You've missed the point of the article.
  - bayindirh 3y ago
    I don't think so, because a) macOS provides correct free space information, b) It explicitly says that "your backup disk is full, and I'll open up some space, so your earliest backup will be at $DATE", before actually deleting any snapshots. Our disagreements stem from the assumption that the reported space is incorrect to begin with, but there's already "disk on space" note on every file, which provides physical size of something. We can argue that the progress may be calculated over that number, but I still think it has its own limitations with performance.
    - tumult 3y ago
      I think that's fair when you consider it all together.
  - pixl97 3y ago
    What happens then if you try to copy that 2TB of 'data' to a filesystem that doesn't support links? 60TB would be used in that case. There are some use cases that are computationally expensive to figure out and don't have a simple/easy answer to solve.
    - tumult 3y ago
      That's not the information that dialog is purporting to display. That's a theoretical thing you've made up for this comment.
      - pixl97 3y ago
        It's a real thing that happens all the time when copying. Delete is a different operation, but now you're asking for a different space calculator when performing delete which will have its own set of bugs and performance issues. Hard links are a pathological case.

by tumult 3y ago

bayindirh 3y ago

However, the code traverses that amount of data. It doesn't matter if you pass over the same inode n times. From OS point of view, there's no difference. Of course you can write a more complicated calculation algorithm, but it'll require tons of syscalls to determine the type of the file handle you're interacting with and will be probably very slow. This is what rustup did inadvertently back in the day, and it caused NTFS to melt down to a halt because of stat() overhead [0]. [0]: https://www.youtube.com/watch?v=qbKGw8MQ0i8 https://www.youtube.com/watch?v=qbKGw8MQ0i8

tumult 3y ago
Why does the user care about how many times an iterator passes over an inode? The Finder is reporting incorrect information to them and may lead them to make bad decisions, like buying unnecessary external storage drives. You've missed the point of the article.
- bayindirh 3y ago
  I don't think so, because a) macOS provides correct free space information, b) It explicitly says that "your backup disk is full, and I'll open up some space, so your earliest backup will be at $DATE", before actually deleting any snapshots. Our disagreements stem from the assumption that the reported space is incorrect to begin with, but there's already "disk on space" note on every file, which provides physical size of something. We can argue that the progress may be calculated over that number, but I still think it has its own limitations with performance.
  - tumult 3y ago
    I think that's fair when you consider it all together.
- pixl97 3y ago
  What happens then if you try to copy that 2TB of 'data' to a filesystem that doesn't support links? 60TB would be used in that case. There are some use cases that are computationally expensive to figure out and don't have a simple/easy answer to solve.
  - tumult 3y ago
    That's not the information that dialog is purporting to display. That's a theoretical thing you've made up for this comment.
    - pixl97 3y ago
      It's a real thing that happens all the time when copying. Delete is a different operation, but now you're asking for a different space calculator when performing delete which will have its own set of bugs and performance issues. Hard links are a pathological case.