Am 11.09.2015 um 00:21 schrieb Jeff Mahoney:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/31/15 8:06 PM, Chris Mason wrote:
On Mon, Aug 31, 2015 at 07:32:09PM +0200, Stefan Priebe -
Profihost AG wrote:
Am 25.08.2015 um 15:51 schrieb Chris Mason :
On Tue, Aug 25, 2015 at 11:00:30AM +02
On Fri, Sep 11, 2015 at 11:58:13AM +0800, Qu Wenruo wrote:
>
>
> Omar Sandoval wrote on 2015/09/10 20:48 -0700:
> >On Fri, Sep 11, 2015 at 09:21:13AM +0800, Qu Wenruo wrote:
> >>Hi Omar,
> >>
> >>Thanks for your patchset.
> >>Quite a nice one, and debug-tree can give better output on space cache.
Omar Sandoval wrote on 2015/09/10 20:48 -0700:
On Fri, Sep 11, 2015 at 09:21:13AM +0800, Qu Wenruo wrote:
Hi Omar,
Thanks for your patchset.
Quite a nice one, and debug-tree can give better output on space cache.
With current implement, space cache is near a black box in debug-tree
output.
A
On Fri, Sep 11, 2015 at 09:21:13AM +0800, Qu Wenruo wrote:
> Hi Omar,
>
> Thanks for your patchset.
> Quite a nice one, and debug-tree can give better output on space cache.
> With current implement, space cache is near a black box in debug-tree
> output.
>
> And current on disk format is not qui
Chandan Rajendra wrote on 2015/09/01 08:03 +0530:
On Monday 31 Aug 2015 22:15:10 Theodore Ts'o wrote:
On Tue, Sep 01, 2015 at 05:49:14AM +0530, Chandan Rajendra wrote:
mkfs.btrfs when invoked on small filesystems by "not" specifying any block
sizes (i.e. mkfs.btrfs -f /dev/sda1) will automati
Josef Bacik wrote on 2015/09/10 16:27 -0400:
When dropping a snapshot we need to account for the qgroup changes. If we drop
the snapshot in all one go then the backref code will fail to find blocks from
the snapshot we dropped since it won't be able to find the root in the fs root
cache. This
Josef Bacik wrote on 2015/09/10 16:27 -0400:
When dropping a snapshot we need to account for the qgroup changes. If we drop
the snapshot in all one go then the backref code will fail to find blocks from
the snapshot we dropped since it won't be able to find the root in the fs root
cache. This
Hi Omar,
Thanks for your patchset.
Quite a nice one, and debug-tree can give better output on space cache.
With current implement, space cache is near a black box in debug-tree
output.
And current on disk format is not quite easy to understand.(In fact,
space cache is restored in tree root, a
On Wed, Sep 09, 2015 at 02:00:23PM +0200, David Sterba wrote:
> On Thu, Sep 03, 2015 at 12:44:27PM -0700, Omar Sandoval wrote:
> > Now we can finally hook up everything so we can actually use free space
> > tree. On the first mount with the free_space_tree mount option, the free
> > space tree will
Chris Mason wrote on 2015/09/10 19:34 -0400:
On Tue, Sep 08, 2015 at 05:08:26PM +0800, Qu Wenruo wrote:
Sorry for the confusing cover letter title.
This patch is no longer RFC now.
It's already a working one, and we're doing stress test to ensure it's
completely OK, but seems quite good for n
Mark Fasheh wrote on 2015/09/10 14:01 -0700:
Hi Qu,
On Tue, Sep 08, 2015 at 04:56:52PM +0800, Qu Wenruo wrote:
[[BUG]]
One of the most common case to trigger the bug is the following method:
1) Enable quota
2) Limit excl of qgroup 5 to 16M
3) Write [0,2M) of a file inside subvol 5 10 times wi
David Sterba wrote on 2015/09/10 17:02 +0200:
Commit 854437ca3c228d8ab3eb24d2efc1c21b5d56a635 ("btrfs-progs:
extent-tree: avoid allocating tree block that crosses stripe boundary")
does not work for 64k nodesize. Due to an off-by-one error, all queries
to check_crossing_stripes will return that
On Thu, Sep 10, 2015 at 10:33:02PM +0100, Filipe David Manana wrote:
> On Thu, Sep 10, 2015 at 10:01 PM, Mark Fasheh wrote:
> > Hi Qu,
> >
> > On Tue, Sep 08, 2015 at 04:56:52PM +0800, Qu Wenruo wrote:
> >> [[BUG]]
> >> One of the most common case to trigger the bug is the following method:
> >> 1
On Tue, Sep 08, 2015 at 05:08:26PM +0800, Qu Wenruo wrote:
> Sorry for the confusing cover letter title.
>
> This patch is no longer RFC now.
> It's already a working one, and we're doing stress test to ensure it's
> completely OK, but seems quite good for now.
>
> To Chris,
>
> I know the timin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/31/15 8:06 PM, Chris Mason wrote:
> On Mon, Aug 31, 2015 at 07:32:09PM +0200, Stefan Priebe -
> Profihost AG wrote:
>>> Am 25.08.2015 um 15:51 schrieb Chris Mason :
>>>
On Tue, Aug 25, 2015 at 11:00:30AM +0200, Christoph Hellwig
wrote:
On Thu, Sep 10, 2015 at 10:01 PM, Mark Fasheh wrote:
> Hi Qu,
>
> On Tue, Sep 08, 2015 at 04:56:52PM +0800, Qu Wenruo wrote:
>> [[BUG]]
>> One of the most common case to trigger the bug is the following method:
>> 1) Enable quota
>> 2) Limit excl of qgroup 5 to 16M
>> 3) Write [0,2M) of a file ins
Hi Qu,
On Tue, Sep 08, 2015 at 04:56:52PM +0800, Qu Wenruo wrote:
> [[BUG]]
> One of the most common case to trigger the bug is the following method:
> 1) Enable quota
> 2) Limit excl of qgroup 5 to 16M
> 3) Write [0,2M) of a file inside subvol 5 10 times without sync
>
> EQUOT will be triggered
When dropping a snapshot we need to account for the qgroup changes. If we drop
the snapshot in all one go then the backref code will fail to find blocks from
the snapshot we dropped since it won't be able to find the root in the fs root
cache. This can lead to us failing to find refs from other r
The backref code will look up the fs_root we're trying to resolve our indirect
refs for, unfortunately we use btrfs_read_fs_root_no_name, which returns -ENOENT
if the ref is 0. This isn't helpful for the qgroup stuff with snapshot delete
as it won't be able to search down the snapshot we are delet
While doing scrub got this warning on v4.2.0
kernel: BTRFS: bdev /dev/sdd errs: wr 13360, rd 21021210, flush 1,
corrupt 0, gen 744
kernel: BTRFS: error (device sdc) in write_all_supers:3548: errno=-5
IO failure (errors while submitting device barriers.)
kernel: BTRFS info (device sdc): forced read
On Thu, Sep 10, 2015 at 05:42:51PM +0200, David Sterba wrote:
> On Wed, Sep 09, 2015 at 10:17:57AM -0700, Darrick J. Wong wrote:
> > I noticed that btrfs won't dedupe more than 16M per call. Any thoughts?
>
> btrfs_ioctl_file_extent_same:
>
> 3138 /*
> 3139 * Limit the total len
On 2015-09-10 11:10, Anna Schumaker wrote:
On 09/09/2015 05:16 PM, Darrick J. Wong wrote:
On Wed, Sep 09, 2015 at 02:52:08PM -0400, Anna Schumaker wrote:
On 09/08/2015 06:39 PM, Darrick J. Wong wrote:
On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote:
On Tue, Sep 8, 2015 at 2:29
On Wed, Sep 09, 2015 at 10:17:57AM -0700, Darrick J. Wong wrote:
> I noticed that btrfs won't dedupe more than 16M per call. Any thoughts?
btrfs_ioctl_file_extent_same:
3138 /*
3139 * Limit the total length we will dedupe for each operation.
3140 * This is intended to b
On 09/09/2015 05:16 PM, Darrick J. Wong wrote:
> On Wed, Sep 09, 2015 at 02:52:08PM -0400, Anna Schumaker wrote:
>> On 09/08/2015 06:39 PM, Darrick J. Wong wrote:
>>> On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote:
On Tue, Sep 8, 2015 at 2:29 PM, Darrick J. Wong
wrote:
Commit 854437ca3c228d8ab3eb24d2efc1c21b5d56a635 ("btrfs-progs:
extent-tree: avoid allocating tree block that crosses stripe boundary")
does not work for 64k nodesize. Due to an off-by-one error, all queries
to check_crossing_stripes will return that all extents cross a stripe
and this will lead to
On 2015-09-10 09:18, Piotr Pawłow wrote:
Hello,
Is there some way to cancel a device remove operation? I have
discovered that if I reboot that will cancel it, but that's not always
possible. What I'm after is something the same as cancelling scrub.
I keep running into situations where I want to
Hello,
Is there some way to cancel a device remove operation? I have discovered that
if I reboot that will cancel it, but that's not always possible. What I'm after
is something the same as cancelling scrub.
I keep running into situations where I want to pause a remove operation for
speed reas
On Thu, Sep 10, 2015 at 11:30:41AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
> This issue was discussed (in the mailing list) during the review of
> the patch titled "btrfs: explictly delete unused block groups in
> close_ctree and ro-remount" and it was agreed that acquiring the
> c
On 2015-09-09 14:52, Anna Schumaker wrote:
On 09/08/2015 06:39 PM, Darrick J. Wong wrote:
On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote:
On Tue, Sep 8, 2015 at 2:29 PM, Darrick J. Wong wrote:
On Tue, Sep 08, 2015 at 09:03:09PM +0100, Pádraig Brady wrote:
On 08/09/15 20:10,
From: Filipe Manana
After commmit e44163e17796 ("btrfs: explictly delete unused block groups
in close_ctree and ro-remount"), added in the 4.3 merge window, we have
calls to btrfs_delete_unused_bgs() while holding the cleaner_mutex.
This can cause a deadlock with a concurrent block group relocati
30 matches
Mail list logo
