A 1GB quota on a dataset you never touch doesn't do you a damn bit of good. It doesn't ensure you will ahve that much free space. It is possible to have a 1TB pool with a 500GB dataset that is set by a quota and *still* store 800GB of data on the pool.
I was talking about reservations, not quotas. And even touched on this issue of having a quota larger than the available space when I talked about having to set the quotas of all the datasets to total less than the pool size.
If you set a dataset with a reservation of 20% of your pool you're pool will fill and you'll *still* be right where you are when you fill your pool. You'll likely have a few corrupt files that couldn't be written to the pool because you overfilled it.
This was my question that I posed most recently in
#46. Will a reservation alleviate the disk full issue. Not to keep files writing when the pool is full, but as a nicer solution than 'cat /dev/null > /some/big/file'.
When the pool fills and data doesn't get written, can you drop the reservation size and free up space by deleting files and snapshots? Fully understanding that this won't restore the data that couldn't be written.
Now let me be perfectly clear: A pool should NOT be filled over 80% full. If the notification emails and stuff aren't sufficient you're also failing to be a good ZFS admin for about a dozen other reasons. If emails aren't enough of a warning ZFS is not for you and you should look elsewhere right now. PERIOD.
As I, and a few others have stated in this thread, these are safe-guards to protect against the issue of not being able to modify the pool. If some process goes haywire and suddenly starts writing terabytes of data and fills the pool, it would be a nice way to remedy the situation without having to resort to hacks like truncating files. Setting a reservation still feels like a hack, but it's at least using ZFS methods to resolve the space issue. I would not be surprised if truncating a file not requiring a transaction to be written is considered a bug that gets fixed some day.
Thinking you're going to use quotas and/or reservations to solve a full pool condition is nothing but a way for you to lie to yourself and then say you are doing good administration. You aren't. You look like a fool and you aren't saving yourself anything.
Of course a pool should stay below 80% in order to retain the best performance, but things happen. I wouldn't be happy if an admin came to me and said a pool was dead because something that shouldn't be allowed to happen did happen. I'd be upset that they didn't have a plan to remedy the situation.
The people in this thread have been discussing a legitimate concern with the implementation of ZFS and looking for good ways to mitigate that issue. Again, it isn't that ZFS can fill up at all, it's that the pool becomes unusable when it does. ZFS should at least allow you to delete files and destroy snapshots and datasets. Keeping a metadata reserve does not sound out of hand at all. But, while this thread has discussed how ZFS could be changed, the primary concern is how to get out of that state. If it's true that quotas and space reservations won't alleviate the issue we're back to truncating files.
And stating that ZFS can't figure out what is going to happen is ridiculous. ZFS knows what the file operation is and it can calculate what metadata is going to change. It can then respond that the operation is allowed or not. It's only extreme situations that I can imagine that would still get into locked out pools if there was a transaction reserve.
Finally, I've seen enough conflicting reports from people that I trust on **both** sides of this discussion that I'm not willing to rule out options yet. If I have to create a new pool and test it myself I will. And I won't consider the result, whatever it is, to be foolish.
