On Fri, Jun 5, 2015 at 4:55 AM, Robbie Ko robbi...@synology.com wrote:
Hi Filipe,
There is another case for 2nd scenario where is_ancestor() can't be used.
So it's a 3rd case and not the 2nd one anymore. We must have an
xfstest for this case too.
Parent snapshot:
| a/ (ino 261)
Hi Filipe,
This case will happen after applying [PATCH] Btrfs: incremental send,
don't delay directory renames unnecessarily.
Because, that patch changes behavior of wait_for_parent_move function.
| a
| b
| c
| d
Move a directory from ancestor to descendant means
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/4/15 7:15 AM, Holger Hoffstätte wrote:
On Wed, 03 Jun 2015 10:47:52 -0400, jeffm wrote:
This patch iterates over the unused chunk space and discards any
regions that are unallocated, regardless of whether they were
ever used. This is a
On Wed, Jun 03, 2015 at 06:16:23PM +0530, Chandan Rajendra wrote:
Consider a file having 10 4k blocks (i.e. blocks in the range [0 - 9]). If the
defrag ioctl was invoked for the block range [3 - 6], then max_to_defrag
should actually have the value 4. Instead in the current code we end up
On Thu, Jun 04, 2015 at 07:18:08PM +0800, Robbie Ko wrote:
@@ -2913,6 +2912,12 @@ static int can_rmdir(struct send_ctx *sctx, u64 dir,
u64 dir_gen,
}
if (loc.objectid send_progress) {
+ struct orphan_dir_info *odi;
+
+
On Fri, 05 Jun 2015 09:08:37 -0400, Jeff Mahoney wrote:
which conflicts with Filipe's patch on Tuesday called Btrfs: check
pending chunks when shrinking fs to avoid corruption:
+if (contains_pending_extent(trans, device, start, len)) {
since trans (returned from
On Wed, Jun 03, 2015 at 02:57:33PM +0800, Dongsheng Yang wrote:
Currently, we can not clear a limitation on a qgroup. Although
there is a 'none' choice provided to user to do it, it does not
work well.
...
Reported-by: Tsutomu Itoh t-i...@jp.fujitsu.com
Signed-off-by: Dongsheng Yang
On Wed, Jun 03, 2015 at 10:55:48AM -0400, je...@suse.com wrote:
From: Jeff Mahoney je...@suse.com
Overloading extent_map-bdev to struct map_lookup * might have started out
as a means to an end, but it's a pattern that's used all over the place
now. Let's get rid of the casting and just add a
On Wed, Jun 03, 2015 at 05:27:03PM +0800, Dongsheng Yang wrote:
If we pass a negative value to command qgroup limit, btrfs-progs
would convert it to unsigned long long silently. That's a little
confusing to user, why I can limit my quota to a negative value.
This patch add a check in
On Thu, Jun 04, 2015 at 11:09:02AM +0800, Anand Jain wrote:
Kindly do not integrated this patch as of now.
As I have just found that, the error reporting when
the default background option is used is not completely
transparent. I need to fix this before this patch.
Understood, thanks
On Wed, Jun 03, 2015 at 02:57:31PM +0800, Dongsheng Yang wrote:
There are two understanding of the '0' value in btrfs qgroup show.
(1) is no-limitation on this qgroup. (2) is the max-limitation is 0.
This patch make it showing in different way.
(1). max-limitation for 0 is still showing
On Wed, Jun 03, 2015 at 05:27:04PM +0800, Dongsheng Yang wrote:
Add a check to error out in the following case:
# ./btrfs qgroup limit T /mnt/
Invalid size argument given
Without this patch, btrfs-progs would parse the input as 0
and continue.
Signed-off-by: Dongsheng Yang
Add a regression test for a problem where attempting to delete the
default subvolume would fail (as expected), but not until after all
submounts under the subvolume were unmounted.
Reviewed-by: Eryu Guan eg...@redhat.com
Signed-off-by: Omar Sandoval osan...@osandov.com
---
v2-v3:
- Update
From: Justin Maggard jmaggar...@gmail.com
Currently it's easy to throw off quota reservations by creating and deleting
files before delayed refs get run. This would be a common problem with temp
files. To illustrate, here's a quick reproducer:
$ for i in $(seq 1 100); do fallocate -l1G tmp; rm
From: Justin Maggard jmaggar...@gmail.com
Both btrfs_add_delayed_tree_ref() and
btrfs_add_delayed_data_ref() have inverted logic when
setting the no_quota value for delayed refs. This is
eventually double-checked in __btrfs_inc_extent_ref() and
__btrfs_free_extent(), but not
I get this error occasionally on the same file. I suspect it is some
interaction between vmware server and btrfs. Besides this error, I
have no ill effects.
Is this a known issue? Is it something that ought to be investigated
to improve btrfs?
I might be able to help find the right folks at
16 matches
Mail list logo
