On Thu, Jan 26, 2017 at 08:48:42AM +0800, Qu Wenruo wrote: > > > At 01/25/2017 10:50 PM, Jeff Mahoney wrote: > > Once a qgroup limit is exceeded, it's impossible to restore normal > > operation to the subvolume without modifying the limit or removing > > the subvolume. This is a surprising situation for many users used > > to the typical workflow with quotas on other file systems where it's > > possible to remove files until the used space is back under the limit. > > > > When we go to unlink a file and start the transaction, we'll hit > > the qgroup limit while trying to reserve space for the items we'll > > modify while removing the file. We discussed last month how best > > to handle this situation and agreed that there is no perfect solution. > > The best principle-of-least-surprise solution is to handle it similarly > > to how we already handle ENOSPC when unlinking, which is to allow > > the operation to succeed with the expectation that it will ultimately > > release space under most circumstances. > > > > This patch modifies the transaction start path to select whether to > > honor the qgroups limits. btrfs_start_transaction_fallback_global_rsv > > is the only caller that skips enforcement. The reservation and tracking > > still happens normally -- it just skips the enforcement step. > > Thanks for the patch. > > The unlink remains as a concern for me since for qgroup there is nothing > like global reserved space for us to do unlink operations unlimitedly. > > So it's very nice for you to address the problem. > > It looks good to me. > > Reviewed-by: Qu Wenruo <quwen...@cn.fujitsu.com>
Queued for 4.11. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
