From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-po-03v.sys.comcast.net ([96.114.154.162]:54050 "EHLO resqmta-po-03v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752224AbcHQAOv (ORCPT ); Tue, 16 Aug 2016 20:14:51 -0400 Date: Tue, 16 Aug 2016 19:09:35 -0500 From: Tim Walberg To: Rakesh Sankeshi Cc: Qu Wenruo , linux-btrfs@vger.kernel.org Subject: Re: btrfs quota issues Message-ID: <20160817000935.GF2367@comcast.net> Reply-To: Tim Walberg References: <4a941169-1845-ba0e-6102-39920e1364b9@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 08/16/2016 16:33 -0700, Rakesh Sankeshi wrote: >> also is there any timeframe on when the qgroup / quota issues would be >> stabilized in btrfs? >> >> Thanks! This may or may not be of interest to you, but for the record, since at least linux 4.2, I've had pretty good luck with what I'd loosely call "non-enforcing quotas" with btrfs - i.e. qgroups enabled so that you can actually track usage, but no limits set, so none of the "deny allocation" logic ever gets hit. It's understandably not the desired end-state - I still have to use daily reports and manual enforcement to keep things in balance, but it's better than not being able to use them at all, especially with the other benefits btrfs brings to the table. If you really need the enforcement, I'm afraid a different FS is the best option right now... -- twalberg@gmail.com