-
Notifications
You must be signed in to change notification settings - Fork 269
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Replace messy disk_usage with existing method
- Loading branch information
Showing
1 changed file
with
9 additions
and
32 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
19efea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This definitely breaks on OSX in certain cases now without the special casing to use 'df'
19efea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bobbysteel
That's strange, statvfs should work just fine under OSX.
Do you know which OSX versions are affected? Do you have any debug log we can look at?
19efea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately it's easily testable without a debug log. There seems to be some sort of overflow issue with the POSIX specification of a 32 bit long int. With 4TB+ storage volumes this causes (expected) unpredictable behavior. There doesn't seem to be a 64-bit version of statvfs on OSX (and there's not statvfs64) that I can find. 'df' works properly.
Example:
Result:
On this particular machine, the 4.6TB value is the correct space. This is a mount point to a Synology share.
19efea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is with blocks and actual free space. This is caused by the implementation of SAMBA you're using.
Same issue here, we check Sickrage's issues to.
19efea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep not trying to argue with you. But this is all plain vanilla OSX. Apple ignores bugs like this from what I've seen. How would you recommend this be fixed?
19efea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since like I said on the other thread this isn't an issue at all for me and there are other people with the same issue as you with really custom Samba installs mainly which are from NAS devices like yours... It sounds more like an issue with the
statvfs
library than with OSX or anything else.Also if it was a "normal" OSX issue there would be a LOT more people complaining. I'm running OSX on my laptop and there are no issues at all like that, even with 5TB+ of space free which is more than 4TB and more than the apparently "overflow" issue you keep talking about even though it states in the
statvfs
documentation that they use the underflow to handle over 4TB's worth of bytes.19efea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alexis - can you suggest what else is going on? This is Synology which is pretty well known and tested, and OSX. I can't explain it better than I have - I'm happy to troubleshoot further but these are pretty standard pieces of equipment, not hacky third party Samba installs. Can you suggest an alternate cause for this or another way to determine where in Apple's Samba implementation this is being caused? From my perspective yes it's an Apple bug. Dunno why statvfs would behave differently with network drives vs local drives but it is...
19efea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not statvfs but the way Synology's Samba install is reporting free space vs free blocks. I'm guessing since Synology allows thin provisioning with that way the drives work it's not showing a correct amount of free blocks vs virtual free space.
Maybe contact them?
19efea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strangely though statvfs works perfectly on the synology itself and no other systems except OSX seem to have this issue
19efea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also mounting with NFS generates the same result so it doesn't seem like only the Synology's Samba install.