Thanks for your inputs.

Another question I had was, is there any way to check what's the
directory/file sizes prior to compression and how much copression
btrfs did, etc? Basicaly some stats around compression and/or dedupe
from btrfs.


On Thu, Aug 11, 2016 at 12:13 PM, Duncan [off-list ref] wrote:

Rakesh Sankeshi posted on Thu, 11 Aug 2016 10:32:03 -0700 as excerpted:

quoted

I set 200GB limit to one user and 100GB to another user.

as soon as I reached 139GB and 53GB each, hitting the quota errors.
anyway to workaround quota functionality on btrfs LZO compressed
filesystem?

The btrfs quota subsystem remains somewhat buggy and unstable.  A lot of
work has gone into it to fix the problems, including rewrites of the
entire subsystem, and it's much better than it used to be, but it's still
a feature that I would recommend not using on btrfs.

My general position is this.  Either you need quotas for your use-case or
you don't.  If you truly need them, you're far better off using a more
mature filesystem with proven quota subsystem reliability.  If you don't
really need them, simply keep the feature off for now, and for however
long it takes to stabilize the feature, which could be some time.

Of course if you're specifically testing quotas in ordered to report
issues and test bugfixes, that's a specific case of needing quota
functionality, and your work is greatly appreciated as it'll help to
eventually make that feature stable and workable for all. =:^)



--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html