5 ms·

Yeah, with ZFS some will make an unused dataset with a small reservation (say 1G) that you can then shrink to delete files if the disk is full.

rincebrain 3y ago
This hasn't been a problem you should be able to hit in ZFS in a long time. It reserves a percent of your pool's total space precisely to avoid having 0 actual free space and only allows using space from that amount if the operation is a net gain on free space.
- p_l 3y ago
  Yeah, a situation where you pool gets suspended due to no space and you can't delete files is considered a bug by OpenZFS.
  - rincebrain 3y ago
    I mean, the pool should never have gotten suspended by that, even before OpenZFS was forked; just ENOSPC on rm.
- aidenn0 3y ago
  Oh, that's good to know. I hit it in the past, but it was long enough ago that ZFS still had format versions.
  - rincebrain 3y ago
    Yeah, the whole dance around slop space, if I remember my archaeology, went in shortly after the fork.
- MarkSweep 3y ago
  For more details about this slop space, see this comment: https://github.com/openzfs/zfs/blob/99741bde59d1d1df0963009bb624ddc105f7d8dc/module/zfs/spa_misc.c#L351 https://github.com/openzfs/zfs/blob/99741bde59d1d1df0963009b...
p_l 3y ago
The recommended solution is to apply a quota on top-level dataset, but that's mainly for preventing fragmentation or runaway writes.
- b112 3y ago
  I think the solution is to not use a filesystem that is broken in this way.
  - p_l 3y ago
    Note that ZFS explicitly has safeguards against total failure. No filesystem will work well with near full state when it comes to fragmentation.
    - b112 3y ago
      This is a whataboutism. Being unable to use the filesystem, due to space full, without arcane knowledge, is not the same as "not working well". This is a brokwn implementation.
      - aidenn0 3y ago
        You're misunderstanding. See the sibling thread where p_l says that this problem has been resolved, and any further occurrence would be treated as a bug. Setting the quota is only done now to reduce fragmentation (ZFS's fragmentation avoidance requires sufficient free space to be effective).
        b112 3y ago
        No, I'm not. They said the "recommended solution" for this issue is to use a quota. They also said it was mainly used for other issues, such as fragmentation. In other words, this was stated as a fix for the file delete issue. How does this invalidate my comment, that this was a broken implementation? It doesn't matter if it will be fixed in the future, or was just fixed.

rincebrain 3y ago

This hasn't been a problem you should be able to hit in ZFS in a long time. It reserves a percent of your pool's total space precisely to avoid having 0 actual free space and only allows using space from that amount if the operation is a net gain on free space.

p_l 3y ago
Yeah, a situation where you pool gets suspended due to no space and you can't delete files is considered a bug by OpenZFS.
- rincebrain 3y ago
  I mean, the pool should never have gotten suspended by that, even before OpenZFS was forked; just ENOSPC on rm.
aidenn0 3y ago
Oh, that's good to know. I hit it in the past, but it was long enough ago that ZFS still had format versions.
- rincebrain 3y ago
  Yeah, the whole dance around slop space, if I remember my archaeology, went in shortly after the fork.
MarkSweep 3y ago
For more details about this slop space, see this comment: https://github.com/openzfs/zfs/blob/99741bde59d1d1df0963009bb624ddc105f7d8dc/module/zfs/spa_misc.c#L351 https://github.com/openzfs/zfs/blob/99741bde59d1d1df0963009b...

p_l 3y ago

The recommended solution is to apply a quota on top-level dataset, but that's mainly for preventing fragmentation or runaway writes.

b112 3y ago
I think the solution is to not use a filesystem that is broken in this way.
- p_l 3y ago
  Note that ZFS explicitly has safeguards against total failure. No filesystem will work well with near full state when it comes to fragmentation.
  - b112 3y ago
    This is a whataboutism. Being unable to use the filesystem, due to space full, without arcane knowledge, is not the same as "not working well". This is a brokwn implementation.
    - aidenn0 3y ago
      You're misunderstanding. See the sibling thread where p_l says that this problem has been resolved, and any further occurrence would be treated as a bug. Setting the quota is only done now to reduce fragmentation (ZFS's fragmentation avoidance requires sufficient free space to be effective).
      - b112 3y ago
        No, I'm not. They said the "recommended solution" for this issue is to use a quota. They also said it was mainly used for other issues, such as fragmentation. In other words, this was stated as a fix for the file delete issue. How does this invalidate my comment, that this was a broken implementation? It doesn't matter if it will be fixed in the future, or was just fixed.