March 2017 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1025058] New: Btrfs: Direct I/O: Fix space accounting
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025058 Bug ID: 1025058 Summary: Btrfs: Direct I/O: Fix space accounting Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: chandan <chandan(a)linux.vnet.ibm.com> Date: Fri, 28 Aug 2015 21:10:13 +0530 Subject: Btrfs: Direct I/O: Fix space accounting Git-commit: 50745b0a7f46f68574cd2b9ae24566bf026e7ebd Patch-mainline: v4.3-rc6 References: revisit The following call trace is seen when generic/095 test is executed, WARNING: CPU: 3 PID: 2769 at /home/chandan/code/repos/linux/fs/btrfs/inode.c:8967 btrfs_destroy_inode+0x284/0x2a0() Modules linked in: CPU: 3 PID: 2769 Comm: umount Not tainted 4.2.0-rc5+ #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20150306_163512-brownie 04/01/2014 ffffffff81c08150 ffff8802ec9cbce8 ffffffff81984058 ffff8802ffd8feb0 0000000000000000 ffff8802ec9cbd28 ffffffff81050385 ffff8802ec9cbd38 ffff8802d12f8588 ffff8802d12f8588 ffff8802f15ab000 ffff8800bb96c0b0 Call Trace: [<ffffffff81984058>] dump_stack+0x45/0x57 [<ffffffff81050385>] warn_slowpath_common+0x85/0xc0 [<ffffffff81050465>] warn_slowpath_null+0x15/0x20 [<ffffffff81340294>] btrfs_destroy_inode+0x284/0x2a0 [<ffffffff8117ce07>] destroy_inode+0x37/0x60 [<ffffffff8117cf39>] evict+0x109/0x170 [<ffffffff8117cfd5>] dispose_list+0x35/0x50 [<ffffffff8117dd3a>] evict_inodes+0xaa/0x100 [<ffffffff81165667>] generic_shutdown_super+0x47/0xf0 [<ffffffff81165951>] kill_anon_super+0x11/0x20 [<ffffffff81302093>] btrfs_kill_super+0x13/0x110 [<ffffffff81165c99>] deactivate_locked_super+0x39/0x70 [<ffffffff811660cf>] deactivate_super+0x5f/0x70 [<ffffffff81180e1e>] cleanup_mnt+0x3e/0x90 [<ffffffff81180ebd>] __cleanup_mnt+0xd/0x10 [<ffffffff81069c06>] task_work_run+0x96/0xb0 [<ffffffff81003a3d>] do_notify_resume+0x3d/0x50 [<ffffffff8198cbc2>] int_signal+0x12/0x17 This means that the inode had non-zero "outstanding extents" during eviction. This occurs because, during direct I/O a task which successfully used up its reserved data space would set BTRFS_INODE_DIO_READY bit and does not clear the bit after finishing the DIO write. A future DIO write could actually fail and the unused reserve space won't be freed because of the previously set BTRFS_INODE_DIO_READY bit. Clearing the BTRFS_INODE_DIO_READY bit in btrfs_direct_IO() caused the following issue, |-----------------------------------+-------------------------------------| | Task A | Task B | |-----------------------------------+-------------------------------------| | Start direct i/o write on inode X.| | | reserve space | | | Allocate ordered extent | | | release reserved space | | | Set BTRFS_INODE_DIO_READY bit. | | | | splice() | | | Transfer data from pipe buffer to | | | destination file. | | | - kmap(pipe buffer page) | | | - Start direct i/o write on | | | inode X. | | | - reserve space | | | - dio_refill_pages() | | | - sdio->blocks_available == 0 | | | - Since a kernel address is | | | being passed instead of a | | | user space address, | | | iov_iter_get_pages() returns | | | -EFAULT. | | | - Since BTRFS_INODE_DIO_READY is | | | set, we don't release reserved | | | space. | | | - Clear BTRFS_INODE_DIO_READY bit.| | -EIOCBQUEUED is returned. | | |-----------------------------------+-------------------------------------| Hence this commit introduces "struct btrfs_dio_data" to track the usage of reserved data space. The remaining unused "reserve space" can now be freed reliably. Signed-off-by: Chandan Rajendra <chandan(a)linux.vnet.ibm.com> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Signed-off-by: Chris Mason <clm(a)fb.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/btrfs_inode.h | 2 -- fs/btrfs/inode.c | 42 +++++++++++++++++++++--------------------- 2 files changed, 21 insertions(+), 23 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025057] New: Btrfs: fix device replace of a missing RAID 5/6 device
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025057 Bug ID: 1025057 Summary: Btrfs: fix device replace of a missing RAID 5/6 device Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Omar Sandoval <osandov(a)fb.com> Date: Fri, 19 Jun 2015 11:52:51 -0700 Subject: Btrfs: fix device replace of a missing RAID 5/6 device Git-commit: 73ff61dbe5edeb1799d7e91c8b0641f87feb75fa Patch-mainline: v4.3-rc1 References: revisit The original implementation of device replace on RAID 5/6 seems to have missed support for replacing a missing device. When this is attempted, we end up calling bio_add_page() on a bio with a NULL ->bi_bdev, which crashes when we try to dereference it. This happens because btrfs_map_block() has no choice but to return us the missing device because RAID 5/6 don't have any alternate mirrors to read from, and a missing device has a NULL bdev. The idea implemented here is to handle the missing device case separately, which better only happen when we're replacing a missing RAID 5/6 device. We use the new BTRFS_RBIO_REBUILD_MISSING operation to reconstruct the data from parity, check it with scrub_recheck_block_checksum(), and write it out with scrub_write_block_to_dev_replace(). Reported-by: Philip <bugzilla(a)philip-seeger.de> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96141 Signed-off-by: Omar Sandoval <osandov(a)fb.com> Signed-off-by: Chris Mason <clm(a)fb.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/scrub.c | 157 +++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 147 insertions(+), 10 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025055] New: Btrfs: remove misleading handling of missing device scrub
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025055 Bug ID: 1025055 Summary: Btrfs: remove misleading handling of missing device scrub Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Omar Sandoval <osandov(a)fb.com> Date: Fri, 19 Jun 2015 11:52:48 -0700 Subject: Btrfs: remove misleading handling of missing device scrub Git-commit: 03679ade86b2b1c370c8790f1ffcbcdef6d49f9f Patch-mainline: v4.3-rc1 References: revisit scrub_submit() claims that it can handle a bio with a NULL block device, but this is misleading, as calling bio_add_page() on a bio with a NULL ->bi_bdev would've already crashed. Delete this, as we're about to properly handle a missing block device. Signed-off-by: Omar Sandoval <osandov(a)fb.com> Signed-off-by: Chris Mason <clm(a)fb.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/scrub.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025053] New: Btrfs: fix shrinking truncate when the no_holes feature is enabled
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025053 Bug ID: 1025053 Summary: Btrfs: fix shrinking truncate when the no_holes feature is enabled Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Filipe Manana <fdmanana(a)suse.com> Date: Sat, 20 Jun 2015 18:20:09 +0100 Subject: Btrfs: fix shrinking truncate when the no_holes feature is enabled Git-commit: c1aa45759e90b4204ab8bce027a925fc7c87d00a Patch-mainline: v4.2-rc6 References: revisit If the no_holes feature is enabled, we attempt to shrink a file to a size that ends up in the middle of a hole and we don't have any file extent items in the fs/subvol tree that go beyond the new file size (or any ordered extents that will insert such file extent items), we end up not updating the inode's disk_i_size, we only update the inode's i_size. This means that after unmounting and mounting the filesystem, or after the inode is evicted and reloaded, its i_size ends up being incorrect (an inode's i_size is set to the disk_i_size field when an inode is loaded). This happens when btrfs_truncate_inode_items() doesn't find any file extent items to drop - in this case it never makes a call to btrfs_ordered_update_i_size() in order to update the inode's disk_i_size. Example reproducer: $ mkfs.btrfs -O no-holes -f /dev/sdd $ mount /dev/sdd /mnt # Create our test file with some data and durably persist it. $ xfs_io -f -c "pwrite -S 0xaa 0 128K" /mnt/foo $ sync # Append some data to the file, increasing its size, and leave a hole # between the old size and the start offset if the following write. So # our file gets a hole in the range [128Kb, 256Kb[. $ xfs_io -c "truncate 160K" /mnt/foo # We expect to see our file with a size of 160Kb, with the first 128Kb # of data all having the value 0xaa and the remaining 32Kb of data all # having the value 0x00. $ od -t x1 /mnt/foo 0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa * 0400000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0500000 # Now cleanly unmount and mount again the filesystem. $ umount /mnt $ mount /dev/sdd /mnt # We expect to get the same result as before, a file with a size of # 160Kb, with the first 128Kb of data all having the value 0xaa and the # remaining 32Kb of data all having the value 0x00. $ od -t x1 /mnt/foo 0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa * 0400000 In the example above the file size/data do not match what they were before the remount. Fix this by always calling btrfs_ordered_update_i_size() with a size matching the size the file was truncated to if btrfs_truncate_inode_items() is not called for a log tree and no file extent items were dropped. This ensures the same behaviour as when the no_holes feature is not enabled. A test case for fstests follows soon. Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/inode.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025051] New: Btrfs: use received_uuid of parent during send
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025051 Bug ID: 1025051 Summary: Btrfs: use received_uuid of parent during send Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Josef Bacik <jbacik(a)fb.com> Date: Thu, 4 Jun 2015 17:17:25 -0400 Subject: Btrfs: use received_uuid of parent during send Git-commit: 37b8d27de5d0079e1ecef2711061048e13054ebe Patch-mainline: v4.2-rc2 References: revisit Neil Horman pointed out a problem where if he did something like this receive A snap A B change B send -p A B and then on another box do recieve A receive B the receive B would fail because we use the UUID of A for the clone sources for B. This makes sense most of the time because normally you are sending from the original sources, not a received source. However when you use a recieved subvol its UUID is going to be something completely different, so if you then try to receive the diff on a different volume it won't find the UUID because the new A will be something else. The only constant is the received uuid. So instead check to see if we have received_uuid set on the root, and if so use that as the clone source, as btrfs receive looks for matches either in received_uuid or uuid. Thanks, Reported-by: Neil Horman <nhorman(a)redhat.com> Signed-off-by: Josef Bacik <jbacik(a)fb.com> Reviewed-by: Hugo Mills <hugo(a)carfax.org.uk> Signed-off-by: Chris Mason <clm(a)fb.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/send.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1025050] New: Btrfs: wake up extent state waiters on unlock through
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025050 Bug ID: 1025050 Summary: Btrfs: wake up extent state waiters on unlock through Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Filipe Manana <fdmanana(a)suse.com> Date: Thu, 14 May 2015 20:41:07 +0100 Subject: Btrfs: wake up extent state waiters on unlock through clear_extent_bits Git-commit: 0f31871f4411b5c0d42fb4403dec83a21a96100b Patch-mainline: v4.2-rc2 References: revisit When we clear an extent state's EXTENT_LOCKED bit with clear_extent_bits() through free_io_failure(), we weren't waking up any tasks waiting for the extent's state EXTENT_LOCKED bit, leading to an hang. So make sure clear_extent_bits() ends up waking up any waiters if the bit EXTENT_LOCKED is supplied by its callers. Zygo Blaxell was experiencing such hangs at inode eviction time after file unlinks. Thanks to him for a set of scripts to reproduce the issue. Reported-by: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Signed-off-by: Chris Mason <clm(a)fb.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/extent_io.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1025049] New: Btrfs: incremental send, check if orphanized dir inode needs delayed
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025049 Bug ID: 1025049 Summary: Btrfs: incremental send, check if orphanized dir inode needs delayed Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Filipe Manana <fdmanana(a)suse.com> Date: Thu, 9 Apr 2015 14:09:14 +0100 Subject: Btrfs: incremental send, check if orphanized dir inode needs delayed rename Git-commit: 8b191a684968e24b34c9894024b37532c68e6ae8 Patch-mainline: v4.2-rc2 References: revisit If a directory inode is orphanized, because some inode previously processed has a new name that collides with the old name of the current inode, we need to check if it needs its rename operation delayed too, as its ancestor-descendent relationship with some other inode might have been reversed between the parent and send snapshots and therefore its rename operation needs to happen after that other inode is renamed. For example, for the following reproducer where this is needed (provided by Robbie Ko): $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt2 $ mkdir -p /mnt/data/n1/n2 $ mkdir /mnt/data/n4 $ mkdir -p /mnt/data/t6/t7 $ mkdir /mnt/data/t5 $ mkdir /mnt/data/t7 $ mkdir /mnt/data/n4/t2 $ mkdir /mnt/data/t4 $ mkdir /mnt/data/t3 $ mv /mnt/data/t7 /mnt/data/n4/t2 $ mv /mnt/data/t4 /mnt/data/n4/t2/t7 $ mv /mnt/data/t5 /mnt/data/n4/t2/t7/t4 $ mv /mnt/data/t6 /mnt/data/n4/t2/t7/t4/t5 $ mv /mnt/data/n1/n2 /mnt/data/n4/t2/t7/t4/t5/t6 $ mv /mnt/data/n1 /mnt/data/n4/t2/t7/t4/t5/t6 $ mv /mnt/data/n4/t2/t7/t4/t5/t6/t7 /mnt/data/n4/t2/t7/t4/t5/t6/n2 $ mv /mnt/data/t3 /mnt/data/n4/t2/t7/t4/t5/t6/n2/t7 $ btrfs subvolume snapshot -r /mnt /mnt/snap1 $ mv /mnt/data/n4/t2/t7/t4/t5/t6/n1 /mnt/data/n4 $ mv /mnt/data/n4/t2 /mnt/data/n4/n1 $ mv /mnt/data/n4/n1/t2/t7/t4/t5/t6/n2 /mnt/data/n4/n1/t2 $ mv /mnt/data/n4/n1/t2/n2/t7/t3 /mnt/data/n4/n1/t2 $ mv /mnt/data/n4/n1/t2/t7/t4/t5/t6 /mnt/data/n4/n1/t2 $ mv /mnt/data/n4/n1/t2/t7/t4 /mnt/data/n4/n1/t2/t6 $ mv /mnt/data/n4/n1/t2/t7 /mnt/data/n4/n1/t2/t3 $ mv /mnt/data/n4/n1/t2/n2/t7 /mnt/data/n4/n1/t2 $ btrfs subvolume snapshot -r /mnt /mnt/snap2 $ btrfs send /mnt/snap1 | btrfs receive /mnt2 $ btrfs send -p /mnt/snap1 /mnt/snap2 | btrfs receive /mnt2 ERROR: send ioctl failed with -12: Cannot allocate memory Where the parent snapshot directory hierarchy is the following: . (ino 256) |-- data/ (ino 257) |-- n4/ (ino 260) |-- t2/ (ino 265) |-- t7/ (ino 264) |-- t4/ (ino 266) |-- t5/ (ino 263) |-- t6/ (ino 261) |-- n1/ (ino 258) |-- n2/ (ino 259) |-- t7/ (ino 262) |-- t3/ (ino 267) And the send snapshot's directory hierarchy is the following: . (ino 256) |-- data/ (ino 257) |-- n4/ (ino 260) |-- n1/ (ino 258) |-- t2/ (ino 265) |-- n2/ (ino 259) |-- t3/ (ino 267) | |-- t7 (ino 264) | |-- t6/ (ino 261) | |-- t4/ (ino 266) | |-- t5/ (ino 263) | |-- t7/ (ino 262) While processing inode 262 we orphanize inode 264 and later attempt to rename inode 264 to its new name/location, which resulted in building an incorrect destination path string for the rename operation with the value "data/n4/t2/t7/t4/t5/t6/n2/t7/t3/t7". This rename operation must have been done only after inode 267 is processed and renamed, as the ancestor-descendent relationship between inodes 264 and 267 was reversed between both snapshots, because otherwise it results in an infinite loop when building the path string for inode 264 when we are processing an inode with a number larger than 264. That loop is the following: start inode 264, send progress of 265 for example parent of 264 -> 267 parent of 267 -> 262 parent of 262 -> 259 parent of 259 -> 261 parent of 261 -> 263 parent of 263 -> 266 parent of 266 -> 264 |--> back to first iteration while current path string length is <= PATH_MAX, and fail with -ENOMEM otherwise So fix this by making the check if we need to delay a directory rename regardless of the current inode having been orphanized or not. A test case for fstests follows soon. Thanks to Robbie Ko for providing a reproducer for this problem. Reported-by: Robbie Ko <robbieko(a)synology.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/send.c | 56 +++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 37 insertions(+), 19 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025048] New: Btrfs: incremental send, don't delay directory renames unnecessarily
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025048 Bug ID: 1025048 Summary: Btrfs: incremental send, don't delay directory renames unnecessarily Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Filipe Manana <fdmanana(a)suse.com> Date: Fri, 27 Mar 2015 17:50:45 +0000 Subject: Btrfs: incremental send, don't delay directory renames unnecessarily Git-commit: 80aa6027561eef12b49031d46fd6724daf1e7fb6 Patch-mainline: v4.2-rc2 References: revisit Even though we delay the rename of directories when they become descendents of other directories that were also renamed in the send root to prevent infinite path build loops, we were doing it in cases where this was not needed and was actually harmful resulting in infinite path build loops as we ended up with a circular dependency of delayed directory renames. Consider the following reproducer: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt2 $ mkdir /mnt/data $ mkdir /mnt/data/n1 $ mkdir /mnt/data/n1/n2 $ mkdir /mnt/data/n4 $ mkdir /mnt/data/n1/n2/p1 $ mkdir /mnt/data/n1/n2/p1/p2 $ mkdir /mnt/data/t6 $ mkdir /mnt/data/t7 $ mkdir -p /mnt/data/t5/t7 $ mkdir /mnt/data/t2 $ mkdir /mnt/data/t4 $ mkdir -p /mnt/data/t1/t3 $ mkdir /mnt/data/p1 $ mv /mnt/data/t1 /mnt/data/p1 $ mkdir -p /mnt/data/p1/p2 $ mv /mnt/data/t4 /mnt/data/p1/p2/t1 $ mv /mnt/data/t5 /mnt/data/n4/t5 $ mv /mnt/data/n1/n2/p1/p2 /mnt/data/n4/t5/p2 $ mv /mnt/data/t7 /mnt/data/n4/t5/p2/t7 $ mv /mnt/data/t2 /mnt/data/n4/t1 $ mv /mnt/data/p1 /mnt/data/n4/t5/p2/p1 $ mv /mnt/data/n1/n2 /mnt/data/n4/t5/p2/p1/p2/n2 $ mv /mnt/data/n4/t5/p2/p1/p2/t1 /mnt/data/n4/t5/p2/p1/p2/n2/t1 $ mv /mnt/data/n4/t5/t7 /mnt/data/n4/t5/p2/p1/p2/n2/t1/t7 $ mv /mnt/data/n4/t5/p2/p1/t1/t3 /mnt/data/n4/t5/p2/p1/p2/n2/t1/t3 $ mv /mnt/data/n4/t5/p2/p1/p2/n2/p1 /mnt/data/n4/t5/p2/p1/p2/n2/t1/t7/p1 $ mv /mnt/data/t6 /mnt/data/n4/t5/p2/p1/p2/n2/t1/t3/t5 $ mv /mnt/data/n4/t5/p2/p1/t1 /mnt/data/n4/t5/p2/p1/p2/n2/t1/t3/t1 $ mv /mnt/data/n1 /mnt/data/n4/t5/p2/p1/p2/n2/t1/t7/p1/n1 $ btrfs subvolume snapshot -r /mnt /mnt/snap1 $ mv /mnt/data/n4/t1 /mnt/data/n4/t5/p2/p1/p2/n2/t1/t7/p1/t1 $ mv /mnt/data/n4/t5/p2/p1/p2/n2/t1 /mnt/data/n4/ $ mv /mnt/data/n4/t5/p2/p1/p2/n2 /mnt/data/n4/t1/n2 $ mv /mnt/data/n4/t1/t7/p1 /mnt/data/n4/t1/n2/p1 $ mv /mnt/data/n4/t1/t3/t1 /mnt/data/n4/t1/n2/t1 $ mv /mnt/data/n4/t1/t3 /mnt/data/n4/t1/n2/t1/t3 $ mv /mnt/data/n4/t5/p2/p1/p2 /mnt/data/n4/t1/n2/p1/p2 $ mv /mnt/data/n4/t1/t7 /mnt/data/n4/t1/n2/p1/t7 $ mv /mnt/data/n4/t5/p2/p1 /mnt/data/n4/t1/n2/p1/p2/p1 $ mv /mnt/data/n4/t1/n2/t1/t3/t5 /mnt/data/n4/t1/n2/p1/p2/t5 $ mv /mnt/data/n4/t5 /mnt/data/n4/t1/n2/p1/p2/p1/t5 $ mv /mnt/data/n4/t1/n2/p1/p2/p1/t5/p2 /mnt/data/n4/t1/n2/p1/p2/p1/p2 $ mv /mnt/data/n4/t1/n2/p1/p2/p1/p2/t7 /mnt/data/n4/t1/t7 $ btrfs subvolume snapshot -r /mnt /mnt/snap2 $ btrfs send /mnt/snap1 | btrfs receive /mnt2 $ btrfs send -p /mnt/snap1 /mnt/snap2 | btrfs receive -vv /mnt2 ERROR: send ioctl failed with -12: Cannot allocate memory This reproducer resulted in an infinite path build loop when building the path for inode 266 because the following circular dependency of delayed directory renames was created: ino 272 <- ino 261 <- ino 259 <- ino 268 <- ino 267 <- ino 261 Where the notation "X <- Y" means the rename of inode X is delayed by the rename of inode Y (X will be renamed after Y is renamed). This resulted in an infinite path build loop of inode 266 because that inode has inode 261 as an ancestor in the send root and inode 261 is in the circular dependency of delayed renames listed above. Fix this by not delaying the rename of a directory inode if an ancestor of the inode in the send root, which has a delayed rename operation, is not also a descendent of the inode in the parent root. Thanks to Robbie Ko for sending the reproducer example. A test case for xfstests follows soon. Reported-by: Robbie Ko <robbieko(a)synology.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/send.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 46 insertions(+), 2 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025047] New: Btrfs: set UNWRITTEN for prealloc'ed extents in fiemap
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025047 Bug ID: 1025047 Summary: Btrfs: set UNWRITTEN for prealloc'ed extents in fiemap Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Josef Bacik <jbacik(a)fb.com> Date: Tue, 19 May 2015 10:44:04 -0400 Subject: Btrfs: set UNWRITTEN for prealloc'ed extents in fiemap Git-commit: 0d2b2372e097cd3b4150d3ec91e79ac3c5cc750e Patch-mainline: v4.2-rc2 References: revisit We should be doing this, it's weird we hadn't been doing this. Signed-off-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: Chris Mason <clm(a)fb.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/extent_io.c | 2 ++ 1 file changed, 2 insertions(+) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1022427] mpv lacks bash-completion
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1022427 Swamp Workflow Management <swamp(a)suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|obs:running:6423:low | -- You are receiving this mail because: You are on the CC list for the bug.

1 0