A disk so full, it couldn't be restored

Re:A disk so full, it couldn't be restored by Dalewyn on Wednesday April 03, 2024 @10:07PM (#39925777)

What would the reasoning be for the file system failing this hard? Filling a partition to 99.999999% capacity always produces a nonsensical situation, but it's usually still recoverable without resorting to DBANing it first.

[ Parent | on HN ]

Re:A disk so full, it couldn't be restored by epmos on Wednesday April 03, 2024 @10:19PM (#39925850)

I do not know the details of Apple's file system, but I wouldn't be surprised if it needs to allocate space for the log (journal) and can't do so.

That isn't reasonable in the sense of "this is what the filesystem should do in this situation" but if the log and user data are allocated from the same pool it is quite possible to exhaust both.

[ Parent | on HN ]

Re:A disk so full, it couldn't be restored by opello on Wednesday April 03, 2024 @10:37PM (#39925974)

I'm so curious about this too. I've done this with ext2 and ext3 in the past and truncating a large file solved the problem if rm wouldn't. It's been long enough I don't remember so specifically though, but certainly wasn't "dd to larger disk and grow the partition" to the rescue.

If it was a journal issue would something akin to using an initramfs (or live environment) and mounting with data=writeback enable removing files? Or maybe APFS doesn't support that?

[ Parent | on HN ]