Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

My best guess at what happened (based on a little knowledge of HFS+ disk structures, but not APFS) is that the journal file also filled up, and since deletion requires writing to it and possibly expanding it, you get into the unusual situation where deletion requires, at least temporarily, more space.

macOS continued to write files until there was just 41K free on the drive.

I've (accidentally) ran both NTFS and FAT32 to 0 bytes free, and it was always possible to delete something even in that situation.

Digging around in forums, I found that Sonoma has broken the SMB/Samba-based networking mount procedure for Time Machine restores, and no one had found a solution. This appears to still be the case in 14.4.

In my experience SMB became unreliable and just unacceptably buggy many years ago, starting around the 10.12-10.13 timeframe; and now it looks like Apple doesn't care about whether it works at all anymore.

I hate to think what people without decades of Mac experience do when confronted with systemic, cascading failures like this when I felt helpless despite what I thought I knew and all the answers I searched for and found on forums.

I don't have "decades of Mac experience", but the first thing I'd try is a fsck --- odd not to see that mentioned here.

If I were asked to recover from this situation, and couldn't just copy the necessary contents of the disk to another one before formatting it and then copying back, I'd get the APFS documentation (https://developer.apple.com/support/downloads/Apple-File-Sys...) and figure out what to edit (with dd and a hex editor) to get some free space.

That's for a journalling filesystem. For CoW filesystems, the issue is that any change to the filesystem is done by making a new file tree containing your change, and then updating the root to point the new tree. Later, garbage collection finds files that are no longer part of an active tree and returns their storage to the pool.

Changes are usually batched to reduce the amount of tree changes to a manageable amount. A bonus of this design is that a filesystem snapshot is just another reference to a particular tree.

This requires space, but CoW filesystems also usually reserve an amount of emergency storage for this reason.

> Sonoma has broken the SMB/Samba-based networking

Apple dropped Samba in favor of their own implementation a long time ago after Samba adopted GPLv3:

https://lists.samba.org/archive/samba-announce/2007/000122.h...

https://www.engadget.com/2011-03-24-apple-to-drop-samba-netw...

Similarly, Apple has resolved the increasingly-aged stock Bash install, eschewing Bash's subsequent GPLv3 licencing, by making zsh the default login shell.

I'd like to see zsh also adopt GPLv3 to call Apple's bluff.

So would I for the lolz but they would probably just switch to fish or dash

https://github.com/fish-shell/fish-shell/blob/master/COPYING

https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/COPY... (Default Ubuntu shell since 6.10)

dash isn't a fully-featured interactive shell, and would be a major step backward from bash. At least with zsh, Apple are moving forward on a feature basis. (And I say this as someone who's still stubbornly set on bash over that newfangled zsh nonsense ;-)

I'm less familiar with fish, but based on a very fuzzy awareness, it's at least fully-featured.

I do encounter dash on a few systems. It's the default shell on my OpenWRT networking kit, for example. I've installed bash where those systems have enough storage to accommodate it.

But that's apparently not working with the same features?

Ah, Apple. SMB has always performed from horribly slowly a few years back, to barely decent recently, but is still way slower than NFS or (oh the irony) Appleshare on the exact same hardware.

Tested a few years ago throughput to a big NAS connected in 10gigEo from a Hackintosh with BlackMagic Disk Speed Test :

* running Windows, SMB achieves 900MB/s

* running MacOS, SMB achieves 200MB/s

* running MacOS, NFS and AFP both achieve 1000MB/s

Anything related to professional work is a sad joke in MacOS, alas.

(People keep repeating that AFP is dead, however it still works fine as a client on my Mac Pro -- and performs so much better than SMB than it's almost comical).

Fun (until you run into it) fact: the same thing is possible with BTRFS and ZFS. If you manage fill it to the brim, you might have a problem. BTRFS tries to become read-only while there is still room for metadata so you can remount it in safe mode and delete something, but no safecguard is perfect.

> ran both NTFS and FAT32 to 0b and was able to delete something.

AFAIK those aren’t journaled, no?

So far, you're the only one who provided a technical explanation for this.

For a networked Time Machine restore you can reinstall MacOS without restoring first and then use the migration utility to restore from a remote Time Machine. That seems to use a different smb binary which works. Still, I find it infuriating that restoring, one of the most important things you do on a machine, is broken and was not caught by QA.

> get into the unusual situation where deletion requires, at least temporarily, more space.

s/unusual/usual/ surely.

Reply on news.ycombinator.com