On 2015/08/05 12:10, Dave Chinner wrote:
On Wed, Aug 05, 2015 at 11:52:36AM +0900, Tsutomu Itoh wrote:
On 2015/08/05 10:57, Dave Chinner wrote:
On Wed, Aug 05, 2015 at 09:39:35AM +0800, Qu Wenruo wrote:
Tsutomu Itoh wrote on 2015/08/05 10:26 +0900:
On 2015/08/05 10:08, Qu Wenruo wrote:
+# As
On Wed, Aug 05, 2015 at 11:52:36AM +0900, Tsutomu Itoh wrote:
> On 2015/08/05 10:57, Dave Chinner wrote:
> >On Wed, Aug 05, 2015 at 09:39:35AM +0800, Qu Wenruo wrote:
> >>Tsutomu Itoh wrote on 2015/08/05 10:26 +0900:
> >>>On 2015/08/05 10:08, Qu Wenruo wrote:
> +# As the reserved space freeing
Tsutomu Itoh wrote on 2015/08/05 11:52 +0900:
On 2015/08/05 10:57, Dave Chinner wrote:
On Wed, Aug 05, 2015 at 09:39:35AM +0800, Qu Wenruo wrote:
Tsutomu Itoh wrote on 2015/08/05 10:26 +0900:
On 2015/08/05 10:08, Qu Wenruo wrote:
+# As the reserved space freeing happens at commit_transactio
On 2015/08/05 10:57, Dave Chinner wrote:
On Wed, Aug 05, 2015 at 09:39:35AM +0800, Qu Wenruo wrote:
Tsutomu Itoh wrote on 2015/08/05 10:26 +0900:
On 2015/08/05 10:08, Qu Wenruo wrote:
+# As the reserved space freeing happens at commit_transaction time,
+# without a transaction commit, no reser
On Wed, Aug 05, 2015 at 09:39:35AM +0800, Qu Wenruo wrote:
> Tsutomu Itoh wrote on 2015/08/05 10:26 +0900:
> >On 2015/08/05 10:08, Qu Wenruo wrote:
> >>+# As the reserved space freeing happens at commit_transaction time,
> >>+# without a transaction commit, no reserved space needs freeing and
> >>+
Tsutomu Itoh wrote on 2015/08/05 10:26 +0900:
On 2015/08/05 10:08, Qu Wenruo wrote:
The regression is introduced in v4.2-rc1, with the big btrfs qgroup
change.
The problem is, qgroup reserved space is never freed, causing even we
increase the limit, we can still hit the EDQUOT much faster than
On 2015/08/05 10:08, Qu Wenruo wrote:
> The regression is introduced in v4.2-rc1, with the big btrfs qgroup
> change.
> The problem is, qgroup reserved space is never freed, causing even we
> increase the limit, we can still hit the EDQUOT much faster than it
> should.
>
> Reported-by: Tsutomu Ito
The regression is introduced in v4.2-rc1, with the big btrfs qgroup
change.
The problem is, qgroup reserved space is never freed, causing even we
increase the limit, we can still hit the EDQUOT much faster than it
should.
Reported-by: Tsutomu Itoh
Signed-off-by: Qu Wenruo
---
tests/btrfs/089
Filipe David Manana wrote on 2015/08/04 14:16 +0100:
On Tue, Aug 4, 2015 at 7:27 AM, Qu Wenruo wrote:
The regression is introduced in v4.2-rc1, with the big btrfs qgroup
change.
The problem is, qgroup reserved space is never freed, causing even we
increase the limit, we can still hit the EDQU
Wasn't this already solved by commit [1] added in the last 4.2-rc?
Ah yes. it does.
Thanks, Anand
--
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
On Tue, Aug 4, 2015 at 1:10 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> I don't remember you saying anything about trying btrfs restore.
I did try it earlier in dry-run mode and it can't do anything:
=
btrfs restore -D /dev/sdc /mnt/saved/
warning, device 2 i
On Tue, Aug 4, 2015 at 4:28 AM, Austin S Hemmelgarn
wrote:
> On 2015-08-04 00:58, John Ettedgui wrote:
>>
>> On Mon, Aug 3, 2015 at 8:01 PM, Qu Wenruo wrote:
>>>
>>> Although the best practice is staying away from such converted fs, either
>>> using pure, newly created btrfs, or convert back to e
On Tue, Aug 4, 2015 at 3:43 PM, Anand Jain wrote:
> When, read_tree_block() returns error it has already freed the extent_buffer
>
> read_tree_block(..)
> {
> ::
> ret = btree_read_extent_buffer_pages(root, buf, 0, parent_transid);
> <== fails
> if (ret) {
> free_e
Here the patch 3/3 below adds a function to handle device offline,
also in this patch the device offline is triggred by the external
sysfs interface.
Patch 1/3 makes it possible to mount a or continue to be rw mounted
(if -o degraded option is set or if tolerated failure is more than
missing) when
As of now mount with missing device with degraded option is
allowed as long as number of missing devices is below the
number of device failure/missing that a group profile could
tolerate.
However there is feature/bug in the btrfs that when write
happens with least number of devices with which degr
RFC:
Btrfs should offline the device in the following context as below..
1) to report that device has failed per the IO errors
2) identify the target for the (hot) replacement
3) avoid further commit error reported against the failing device and
4) fix the bug which would unmount btrfs (in some sy
When, read_tree_block() returns error it has already freed the extent_buffer
read_tree_block(..)
{
::
ret = btree_read_extent_buffer_pages(root, buf, 0, parent_transid); <==
fails
if (ret) {
free_extent_buffer(buf); <=== its freed already
return ERR
On Mon, Aug 3, 2015 at 9:01 PM, Qu Wenruo wrote:
> Oh, converted...
> That's too bad. :(
>
> [[What's wrong with convert]]
> Although btrfs is flex enough in theory to fit itself into the free space of
> ext* and works fine,
> But in practice, ext* is too fragmental in the standard of btrfs, not
On Tue, Aug 4, 2015 at 7:27 AM, Qu Wenruo wrote:
> The regression is introduced in v4.2-rc1, with the big btrfs qgroup
> change.
> The problem is, qgroup reserved space is never freed, causing even we
> increase the limit, we can still hit the EDQUOT much faster than it
> should.
>
> Reported-by:
On 2015-08-04 00:58, John Ettedgui wrote:
On Mon, Aug 3, 2015 at 8:01 PM, Qu Wenruo wrote:
Although the best practice is staying away from such converted fs, either
using pure, newly created btrfs, or convert back to ext* before any balance.
Unfortunately I don't have enough hard drive space
20 matches
Mail list logo