5 ms·

ZFS had this issue (I believe fixed) workaround was to pick up one large file that you wanted to delete and do `echo -n > /the/unimportant/file` once the file w

• rcthompson 7y ago
  What happens if the file has already found its way into a snapshot? Then presumably that command will not free any space.
  • takeda 7y ago
    Well, rm wouldn't free the space either so you either would remove the snapshot or chose a different file.
  • pletnes 7y ago
    True. For me, I freed up space by nuking old snapshots, when I ran into this on btrfs.
• loeg 7y ago
  See also: 'truncate -s 0 /the/file'
• pfranz 7y ago
  Yep. I had this happen a few weeks ago (I'm not sure how much maintenance the server has had since it was set up 2-3 years previous). Thankfully, after seeing whatever the error was ("No space left on device" or something) and furrowing my brow it seemed obvious enough to try without having to search for a solution. It seemed just dumb enough to work.
• chungy 7y ago
  ZFS reserves 1/64 of every disk precisely so it can't be truly fully allocated. It leaves enough room to delete snapshots, truncate files, and so forth. Mind that everything is copy-on-write, you can't do anything, even metadata changes, without allocating new blocks. It needs the reserve space.
  • tobias3 7y ago
    I had a ZFS bug once where they increased the amount reserved in a new release which caused my file system to be 100% and me unable to delete anything until I went back to the previous release. Btrfs uses the the disk completely. This is harder to do (also compared to e.g. ext4 reserving a fixed amount of inode space which may be unused when the disk is full). At some point they added an in-memory "global reserve" metadata space which allows you to delete stuff even if the file system is full.