4 ms·

You're making the mistake that you're accusing the article of. Of course the author knows these things. As you just showed. Yet, the Finder GUI still reports ba

by tumult 3y ago

You're making the mistake that you're accusing the article of. Of course the author knows these things. As you just showed. Yet, the Finder GUI still reports bad information. Information that can mislead users into making bad decisions. That's what this article is complaining about. The article is talking about Finder, the GUI. It's showing screenshots. It's not talking about probing for CoW status using CLI filesystem tools. What are regular users supposed to do? A sanity check would at least have the Finder report nothing instead of incorrect information.

bayindirh 3y ago
However, the information is not wrong to begin with. You can extract that amount of data from the disk if you copy the filesystem to another filesystem which does not support these features.
- 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.
userbinator 3y ago
You're making the same mistake if you think that's "incorrect information", because it isn't --- there is a clear and logical reason why the sizes are reported the way they are, and if you'd only take some effort to learn instead of complaining because they don't fit your incorrect assumptions, you'd understand. A sanity check would at least have the Finder report nothing instead of incorrect information. You're saying to just not show any size at all if the filesystem contains more data than its capacity, which is basically going to be 100% of the time after enough backups are made? WTF. That makes even less sense. I'm not one to trust AI much at all, but I bet even an LLM these days would know and tell you why the total size of all the files on a filesystem can appear to exceed the capacity of the storage device.
- tumult 3y ago
  > You're making the same mistake if you think that's "incorrect information" No, that would be a different type of mistake. > you'd only take some effort to learn instead of complaining because they don't fit your incorrect assumptions I know exactly why it reports it like this. That wasn't the point of the article, and not the point of my reply. > You're saying to just not show any size at all if the filesystem contains more data than its capacity, which is basically going to be 100% of the time after enough backups are made? WTF. That makes even less sense. No, not 100% of the time. But it would be a significant portion of time, yes. The Finder should probably not even try to report the information like this if it's going to be misleading such a high percentage of the time, if Apple is not going to add a better way for users to account for where all of the space on their drives is going. > I'm not one to trust AI much at all, but I bet even an LLM these days would know and tell you why the total size of all the files on a filesystem can appear to exceed the capacity of the storage device. I tried to find a way to interpret this other than, "you should just use ChatGPT as a person to talk to, because ChatGPT is smarter than you and could explain to you how filesystems work," but I wasn't able to.
  - fragmede 3y ago
    Why did you add > because ChatGPT is smarter than you ? It's really weird framing.
stetrain 3y ago
Saying that finder should sum file sizes in a way that accounts for this makes sense. I'm not sure adding a separate "Sanity check" would help though. If the sanity check is that the reported file sizes shouldn't exceed the disk size, that's still a lie. If you have 1000 duplicate 10GB files that are sharing storage blocks in the file system, that's either 10TB or 10GB of stored files depending on how you count it. Reporting 2TB because that's the size of the disk is a less accurate answer than either of those.
- tumult 3y ago
  Sanity check, not min().
  - stetrain 3y ago
    What value is sane in this case?

by tumult 3y ago

bayindirh 3y ago

However, the information is not wrong to begin with. You can extract that amount of data from the disk if you copy the filesystem to another filesystem which does not support these features.

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.

userbinator 3y ago

You're making the same mistake if you think that's "incorrect information", because it isn't --- there is a clear and logical reason why the sizes are reported the way they are, and if you'd only take some effort to learn instead of complaining because they don't fit your incorrect assumptions, you'd understand. A sanity check would at least have the Finder report nothing instead of incorrect information. You're saying to just not show any size at all if the filesystem contains more data than its capacity, which is basically going to be 100% of the time after enough backups are made? WTF. That makes even less sense. I'm not one to trust AI much at all, but I bet even an LLM these days would know and tell you why the total size of all the files on a filesystem can appear to exceed the capacity of the storage device.

tumult 3y ago
> You're making the same mistake if you think that's "incorrect information" No, that would be a different type of mistake. > you'd only take some effort to learn instead of complaining because they don't fit your incorrect assumptions I know exactly why it reports it like this. That wasn't the point of the article, and not the point of my reply. > You're saying to just not show any size at all if the filesystem contains more data than its capacity, which is basically going to be 100% of the time after enough backups are made? WTF. That makes even less sense. No, not 100% of the time. But it would be a significant portion of time, yes. The Finder should probably not even try to report the information like this if it's going to be misleading such a high percentage of the time, if Apple is not going to add a better way for users to account for where all of the space on their drives is going. > I'm not one to trust AI much at all, but I bet even an LLM these days would know and tell you why the total size of all the files on a filesystem can appear to exceed the capacity of the storage device. I tried to find a way to interpret this other than, "you should just use ChatGPT as a person to talk to, because ChatGPT is smarter than you and could explain to you how filesystems work," but I wasn't able to.
- fragmede 3y ago
  Why did you add > because ChatGPT is smarter than you ? It's really weird framing.

stetrain 3y ago

Saying that finder should sum file sizes in a way that accounts for this makes sense. I'm not sure adding a separate "Sanity check" would help though. If the sanity check is that the reported file sizes shouldn't exceed the disk size, that's still a lie. If you have 1000 duplicate 10GB files that are sharing storage blocks in the file system, that's either 10TB or 10GB of stored files depending on how you count it. Reporting 2TB because that's the size of the disk is a less accurate answer than either of those.

tumult 3y ago
Sanity check, not min().
- stetrain 3y ago
  What value is sane in this case?