[Kernel-packages] [Bug 1809872] Re: btrfs send / receive command with -f argument position in btrfs_kernel_fixes is causing failures on B
** Tags added: cscc -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1809872 Title: btrfs send / receive command with -f argument position in btrfs_kernel_fixes is causing failures on B Status in ubuntu-kernel-tests: Fix Released Status in linux package in Ubuntu: Invalid Bug description: This issue is different from bug 1809869. Test failed with: ERROR: unable to resolve -f And: btrfs receive: too many arguments This patch does exist in Bionic kernel tree. Invoking test 29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5 fix 29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5 Btrfs: send, don't send rmdir for same target multiple times When doing an incremental send, if we delete a directory that has N > 1 hardlinks for the same file and that file has the highest inode number inside the directory contents, an incremental send would send N times an rmdir operation against the directory. This made the btrfs receive command fail on the second rmdir instruction, as the target directory didn't exist anymore. btrfs-progs v4.15.1 See http://btrfs.wiki.kernel.org for more information. Performing full device TRIM /dev/loop0 (1.00GiB) ... Label: (null) UUID: b9297d7d-f8b6-469e-b3c5-64ac1bf1e3d8 Node size: 16384 Sector size:4096 Filesystem size:1.00GiB Block group profiles: Data: single8.00MiB Metadata: DUP 51.19MiB System: DUP 8.00MiB SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: IDSIZE PATH 1 1.00GiB /dev/loop0 Create a readonly snapshot of '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5' in '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5/snap1' ERROR: unable to resolve -f Create a readonly snapshot of '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5' in '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5/snap2' ERROR: unable to resolve -f btrfs-progs v4.15.1 See http://btrfs.wiki.kernel.org for more information. Performing full device TRIM /dev/loop0 (1.00GiB) ... Label: (null) UUID: e6351943-c767-4339-b662-609e80dae55b Node size: 16384 Sector size:4096 Filesystem size:1.00GiB Block group profiles: Data: single8.00MiB Metadata: DUP 51.19MiB System: DUP 8.00MiB SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: IDSIZE PATH 1 1.00GiB /dev/loop0 btrfs receive: too many arguments usage: btrfs receive [options] btrfs receive --dump [options] Receive subvolumes from a stream Receives one or more subvolumes that were previously sent with btrfs send. The received subvolumes are stored into MOUNT. The receive will fail in case the receiving subvolume already exists. It will also fail in case a previously received subvolume has been changed after it was received. After receiving a subvolume, it is immediately set to read-only. -v increase verbosity about performed actions -f FILE read the stream from FILE instead of stdin -e terminate after receiving an marker in the stream. Without this option the receiver side terminates only in case of an error on end of file. -C|--chroot confine the process to using chroot -E|--max-errors NERR terminate as soon as NERR errors occur while stream processing commands from the stream. Default value is 1. A value of 0 means no limit. -m ROOTMOUNT the root mount point of the destination filesystem. If /proc is not accessible, use this to tell us where this file system is mounted. --dump dump stream metadata, one line per operation, does not require the MOUNT parameter btrfs receive: too many arguments usage: btrfs receive [options] btrfs receive --dump [options] Receive subvolumes from a stream Receives one or more subvolumes that were previously sent with btrfs send. The received subvolumes are stored into MOUNT. The receive will fail in case the receiving subvolume already exists. It will also fail in case a previously received subvolume has been changed after it was received. After receiving a subvolume, it is immediately set to read-only. -v increase verbosity about performed actions -f FILE
[Kernel-packages] [Bug 1809872] Re: btrfs send / receive command with -f argument position in btrfs_kernel_fixes is causing failures on B
https://kernel.ubuntu.com/git/ubuntu/autotest-client- tests.git/commit/?id=058bd865bd27b2b2fc097c6e490b38b0891141f6 ** Changed in: ubuntu-kernel-tests Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1809872 Title: btrfs send / receive command with -f argument position in btrfs_kernel_fixes is causing failures on B Status in ubuntu-kernel-tests: Fix Released Status in linux package in Ubuntu: Invalid Bug description: This issue is different from bug 1809869. Test failed with: ERROR: unable to resolve -f And: btrfs receive: too many arguments This patch does exist in Bionic kernel tree. Invoking test 29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5 fix 29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5 Btrfs: send, don't send rmdir for same target multiple times When doing an incremental send, if we delete a directory that has N > 1 hardlinks for the same file and that file has the highest inode number inside the directory contents, an incremental send would send N times an rmdir operation against the directory. This made the btrfs receive command fail on the second rmdir instruction, as the target directory didn't exist anymore. btrfs-progs v4.15.1 See http://btrfs.wiki.kernel.org for more information. Performing full device TRIM /dev/loop0 (1.00GiB) ... Label: (null) UUID: b9297d7d-f8b6-469e-b3c5-64ac1bf1e3d8 Node size: 16384 Sector size:4096 Filesystem size:1.00GiB Block group profiles: Data: single8.00MiB Metadata: DUP 51.19MiB System: DUP 8.00MiB SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: IDSIZE PATH 1 1.00GiB /dev/loop0 Create a readonly snapshot of '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5' in '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5/snap1' ERROR: unable to resolve -f Create a readonly snapshot of '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5' in '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5/snap2' ERROR: unable to resolve -f btrfs-progs v4.15.1 See http://btrfs.wiki.kernel.org for more information. Performing full device TRIM /dev/loop0 (1.00GiB) ... Label: (null) UUID: e6351943-c767-4339-b662-609e80dae55b Node size: 16384 Sector size:4096 Filesystem size:1.00GiB Block group profiles: Data: single8.00MiB Metadata: DUP 51.19MiB System: DUP 8.00MiB SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: IDSIZE PATH 1 1.00GiB /dev/loop0 btrfs receive: too many arguments usage: btrfs receive [options] btrfs receive --dump [options] Receive subvolumes from a stream Receives one or more subvolumes that were previously sent with btrfs send. The received subvolumes are stored into MOUNT. The receive will fail in case the receiving subvolume already exists. It will also fail in case a previously received subvolume has been changed after it was received. After receiving a subvolume, it is immediately set to read-only. -v increase verbosity about performed actions -f FILE read the stream from FILE instead of stdin -e terminate after receiving an marker in the stream. Without this option the receiver side terminates only in case of an error on end of file. -C|--chroot confine the process to using chroot -E|--max-errors NERR terminate as soon as NERR errors occur while stream processing commands from the stream. Default value is 1. A value of 0 means no limit. -m ROOTMOUNT the root mount point of the destination filesystem. If /proc is not accessible, use this to tell us where this file system is mounted. --dump dump stream metadata, one line per operation, does not require the MOUNT parameter btrfs receive: too many arguments usage: btrfs receive [options] btrfs receive --dump [options] Receive subvolumes from a stream Receives one or more subvolumes that were previously sent with btrfs send. The received subvolumes are stored into MOUNT. The receive will fail in case the receiving subvolume already exists. It will also fail in case a previously received subvolume has been changed after it was
[Kernel-packages] [Bug 1809872] Re: btrfs send / receive command with -f argument position in btrfs_kernel_fixes is causing failures on B
In Btrfs v3.12 on Trusty, the --help shows the identical layout: * btrfs send [-ve] [-p ] [-c ] [-f ] * btrfs receive [-ve] [-f ] So we should be able to fix this once for all. ** Changed in: ubuntu-kernel-tests Assignee: (unassigned) => Po-Hsu Lin (cypressyew) ** Changed in: ubuntu-kernel-tests Importance: Undecided => Medium ** Changed in: ubuntu-kernel-tests Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1809872 Title: btrfs send / receive command with -f argument position in btrfs_kernel_fixes is causing failures on B Status in ubuntu-kernel-tests: In Progress Status in linux package in Ubuntu: Invalid Bug description: This issue is different from bug 1809869. Test failed with: ERROR: unable to resolve -f And: btrfs receive: too many arguments This patch does exist in Bionic kernel tree. Invoking test 29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5 fix 29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5 Btrfs: send, don't send rmdir for same target multiple times When doing an incremental send, if we delete a directory that has N > 1 hardlinks for the same file and that file has the highest inode number inside the directory contents, an incremental send would send N times an rmdir operation against the directory. This made the btrfs receive command fail on the second rmdir instruction, as the target directory didn't exist anymore. btrfs-progs v4.15.1 See http://btrfs.wiki.kernel.org for more information. Performing full device TRIM /dev/loop0 (1.00GiB) ... Label: (null) UUID: b9297d7d-f8b6-469e-b3c5-64ac1bf1e3d8 Node size: 16384 Sector size:4096 Filesystem size:1.00GiB Block group profiles: Data: single8.00MiB Metadata: DUP 51.19MiB System: DUP 8.00MiB SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: IDSIZE PATH 1 1.00GiB /dev/loop0 Create a readonly snapshot of '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5' in '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5/snap1' ERROR: unable to resolve -f Create a readonly snapshot of '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5' in '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5/snap2' ERROR: unable to resolve -f btrfs-progs v4.15.1 See http://btrfs.wiki.kernel.org for more information. Performing full device TRIM /dev/loop0 (1.00GiB) ... Label: (null) UUID: e6351943-c767-4339-b662-609e80dae55b Node size: 16384 Sector size:4096 Filesystem size:1.00GiB Block group profiles: Data: single8.00MiB Metadata: DUP 51.19MiB System: DUP 8.00MiB SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: IDSIZE PATH 1 1.00GiB /dev/loop0 btrfs receive: too many arguments usage: btrfs receive [options] btrfs receive --dump [options] Receive subvolumes from a stream Receives one or more subvolumes that were previously sent with btrfs send. The received subvolumes are stored into MOUNT. The receive will fail in case the receiving subvolume already exists. It will also fail in case a previously received subvolume has been changed after it was received. After receiving a subvolume, it is immediately set to read-only. -v increase verbosity about performed actions -f FILE read the stream from FILE instead of stdin -e terminate after receiving an marker in the stream. Without this option the receiver side terminates only in case of an error on end of file. -C|--chroot confine the process to using chroot -E|--max-errors NERR terminate as soon as NERR errors occur while stream processing commands from the stream. Default value is 1. A value of 0 means no limit. -m ROOTMOUNT the root mount point of the destination filesystem. If /proc is not accessible, use this to tell us where this file system is mounted. --dump dump stream metadata, one line per operation, does not require the MOUNT parameter btrfs receive: too many arguments usage: btrfs receive [options] btrfs receive --dump [options] Receive subvolumes from a stream Receives one or more subvolumes that were previously sent with btrfs send. The
[Kernel-packages] [Bug 1809872] Re: btrfs send / receive command with -f argument position in btrfs_kernel_fixes is causing failures on B
This issue is not related to the kernel, for btrfs-progs v4.15.1 on Bionic, the btrfs send / receive command should be: * btrfs send [-ve] [-p ] [-c ] [-f ] [...] * btrfs receive [options] So the btrfs send in the script should be changed from: btrfs send $MNT/snap1 -f $TMP/base.send To: btrfs send -f $TMP/base.send $MNT/snap1 For receive, it should be changed from: btrfs receive $MNT -f $TMP/base.send To: btrfs receive -f $TMP/base.send $MNT This change should be tested across distros, otherwise we need to use different command layout for different version of btrfstools. ** Summary changed: - 29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5 in btrfs_kernel_fixes failed on B + btrfs send / receive command with -f argument position in btrfs_kernel_fixes is causing failures on B ** Changed in: linux (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1809872 Title: btrfs send / receive command with -f argument position in btrfs_kernel_fixes is causing failures on B Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Invalid Bug description: This issue is different from bug 1809869. Test failed with: ERROR: unable to resolve -f And: btrfs receive: too many arguments This patch does exist in Bionic kernel tree. Invoking test 29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5 fix 29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5 Btrfs: send, don't send rmdir for same target multiple times When doing an incremental send, if we delete a directory that has N > 1 hardlinks for the same file and that file has the highest inode number inside the directory contents, an incremental send would send N times an rmdir operation against the directory. This made the btrfs receive command fail on the second rmdir instruction, as the target directory didn't exist anymore. btrfs-progs v4.15.1 See http://btrfs.wiki.kernel.org for more information. Performing full device TRIM /dev/loop0 (1.00GiB) ... Label: (null) UUID: b9297d7d-f8b6-469e-b3c5-64ac1bf1e3d8 Node size: 16384 Sector size:4096 Filesystem size:1.00GiB Block group profiles: Data: single8.00MiB Metadata: DUP 51.19MiB System: DUP 8.00MiB SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: IDSIZE PATH 1 1.00GiB /dev/loop0 Create a readonly snapshot of '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5' in '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5/snap1' ERROR: unable to resolve -f Create a readonly snapshot of '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5' in '/tmp/mnt-29d6d30f5c8aa58b04f40a58442df3bcaae5a1d5/snap2' ERROR: unable to resolve -f btrfs-progs v4.15.1 See http://btrfs.wiki.kernel.org for more information. Performing full device TRIM /dev/loop0 (1.00GiB) ... Label: (null) UUID: e6351943-c767-4339-b662-609e80dae55b Node size: 16384 Sector size:4096 Filesystem size:1.00GiB Block group profiles: Data: single8.00MiB Metadata: DUP 51.19MiB System: DUP 8.00MiB SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: IDSIZE PATH 1 1.00GiB /dev/loop0 btrfs receive: too many arguments usage: btrfs receive [options] btrfs receive --dump [options] Receive subvolumes from a stream Receives one or more subvolumes that were previously sent with btrfs send. The received subvolumes are stored into MOUNT. The receive will fail in case the receiving subvolume already exists. It will also fail in case a previously received subvolume has been changed after it was received. After receiving a subvolume, it is immediately set to read-only. -v increase verbosity about performed actions -f FILE read the stream from FILE instead of stdin -e terminate after receiving an marker in the stream. Without this option the receiver side terminates only in case of an error on end of file. -C|--chroot confine the process to using chroot -E|--max-errors NERR terminate as soon as NERR errors occur while stream processing commands from the stream. Default value is 1. A value of 0 means no limit. -m ROOTMOUNT the root mount point of the destination filesystem. If /proc is not
