3 ms·

So, I generally like APFS, especially because I can have a case-sensitive volume for git repositories without stealing space from the root volume. However, has

So, I generally like APFS, especially because I can have a case-sensitive volume for git repositories without stealing space from the root volume. However, has Apple fixed the issue where filling up the hard drive makes it impossible to delete files to free up some space?

pfranz 6y ago
I've hit this on other filesystems and I think I ended up doing: echo "" > largefile Then you can delete your files. Not sure if it'll work on APFS.
layoutIfNeeded 6y ago
Nope. I'm living on the edge with my 256gb MBP, and if it fills up the only recourse is rebooting, which frees up the swap file so you have enough space to delete things...
- post_break 6y ago
  I read that onyx can delete snapshots without needing to reboot.
jamiek88 6y ago
aaaah! That explains it! This happened to me recently, couldn’t get my head round it but a reboot fixed things so I didn’t investigate more. Reboot must delete the swap or something.
curt15 6y ago
This is a fundamental problem of all copy-on-write filesystems. With btrfs, a quick fix is to plug in a spare usb stick whose space btrfs can borrow in order to delete files on the main drive.
- fiddlerwoaroof 6y ago
  I might be missing something, but couldn’t you reserve a couple gigs of scratch space for this?
  - diegocg 6y ago
    Btrfs actually reserves some space so that these operations always succeed. There has been bugs but that's the intention.
  - cmurf 6y ago
    Btrfs has separate metadata and data block groups, allocated dynamically since some workloads can be light or heavy on metadata. And the data:metadata usage ratio can change after allocation and freeing space by deleting files. The idea of converting between block groups is being kicked around. At this point it is kind of a "last mile" sort of problem, not that common. But annoying for those who run into it because it's non-obvious how to get out of it. Safest option is to just look at 'btrfs fi us' and see which type of block group is the least full. Do a filtered balance on it. e.g. Use something like '-dusage=5' to essentially get rid of any data block groups that are 5% or less full. Their data extents get moved to other block groups. Now that space is "unallocated" and can be allocated into new metadata block groups. These sorts of gymnastics should be rare. There is https://github.com/kdave/btrfsmaintenance https://github.com/kdave/btrfsmaintenance that will do them automatically for those who encounter the problem with their particular workload more often than they care to deal with manually. I never have to manually balance, and I also don't use the automated scripts - it's been years since I've hit enospc that wasn't a case of a 100% full file system.
    - fiddlerwoaroof 6y ago
      Sorry, I meant “couldn’t the developers of APFS reserve a couple gigs”. I assume there’s some implementation detail that makes this complicated.

pfranz 6y ago

I've hit this on other filesystems and I think I ended up doing: echo "" > largefile Then you can delete your files. Not sure if it'll work on APFS.

layoutIfNeeded 6y ago

Nope. I'm living on the edge with my 256gb MBP, and if it fills up the only recourse is rebooting, which frees up the swap file so you have enough space to delete things...

post_break 6y ago
I read that onyx can delete snapshots without needing to reboot.

jamiek88 6y ago

aaaah! That explains it! This happened to me recently, couldn’t get my head round it but a reboot fixed things so I didn’t investigate more. Reboot must delete the swap or something.

curt15 6y ago

This is a fundamental problem of all copy-on-write filesystems. With btrfs, a quick fix is to plug in a spare usb stick whose space btrfs can borrow in order to delete files on the main drive.

fiddlerwoaroof 6y ago
I might be missing something, but couldn’t you reserve a couple gigs of scratch space for this?
- diegocg 6y ago
  Btrfs actually reserves some space so that these operations always succeed. There has been bugs but that's the intention.
- cmurf 6y ago
  Btrfs has separate metadata and data block groups, allocated dynamically since some workloads can be light or heavy on metadata. And the data:metadata usage ratio can change after allocation and freeing space by deleting files. The idea of converting between block groups is being kicked around. At this point it is kind of a "last mile" sort of problem, not that common. But annoying for those who run into it because it's non-obvious how to get out of it. Safest option is to just look at 'btrfs fi us' and see which type of block group is the least full. Do a filtered balance on it. e.g. Use something like '-dusage=5' to essentially get rid of any data block groups that are 5% or less full. Their data extents get moved to other block groups. Now that space is "unallocated" and can be allocated into new metadata block groups. These sorts of gymnastics should be rare. There is https://github.com/kdave/btrfsmaintenance https://github.com/kdave/btrfsmaintenance that will do them automatically for those who encounter the problem with their particular workload more often than they care to deal with manually. I never have to manually balance, and I also don't use the automated scripts - it's been years since I've hit enospc that wasn't a case of a 100% full file system.
  - fiddlerwoaroof 6y ago
    Sorry, I meant “couldn’t the developers of APFS reserve a couple gigs”. I assume there’s some implementation detail that makes this complicated.