RE: [PATCH v2] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

Hi, Sean Fu > -Original Message- > From: Sean Fu [mailto:fxinr...@gmail.com] > Sent: Tuesday, September 06, 2016 11:51 AM > To: dste...@suse.com > Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com; > zhao...@cn.fujitsu.com; linux-ker...@vger.kernel.org; >

Re: [PATCH] fstests: common: Enhance _exclude_scratch_mount_option to handle multiply options and generic fs type

At 09/06/2016 12:20 PM, Eryu Guan wrote: On Mon, Sep 05, 2016 at 03:13:33PM +0800, Qu Wenruo wrote: Enhance _exclude_scratch_mount_option() function to get real mount options from $MOUNT_OPTIONS. This seems unnecessarily complex to me. Considering the fact that we didn't specify any other

Re: [PATCH] fstests: common: Enhance _exclude_scratch_mount_option to handle multiply options and generic fs type

On Mon, Sep 05, 2016 at 03:13:33PM +0800, Qu Wenruo wrote: > Enhance _exclude_scratch_mount_option() function to get real mount > options from $MOUNT_OPTIONS. This seems unnecessarily complex to me. > > Now it can understand and extract real mount option from string like > "-o opt1,opt2

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

On 9/5/16 11:05 PM, Jeff Mahoney wrote: > On 9/5/16 3:56 AM, Qu Wenruo wrote: >> >> >> At 09/05/2016 09:19 AM, Zhao Lei wrote: >>> Hi, Sean Fu >>> From: Sean Fu [mailto:fxinr...@gmail.com] Sent: Sunday, September 04, 2016 7:54 PM To: dste...@suse.com Cc: c...@fb.com;

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

On 9/5/16 3:56 AM, Qu Wenruo wrote: > > > At 09/05/2016 09:19 AM, Zhao Lei wrote: >> Hi, Sean Fu >> >>> From: Sean Fu [mailto:fxinr...@gmail.com] >>> Sent: Sunday, September 04, 2016 7:54 PM >>> To: dste...@suse.com >>> Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com; >>>

Re: btrfs send extremely slow (almost stuck)

At 09/06/2016 05:29 AM, Oliver Freyermuth wrote: Am 05.09.2016 um 07:21 schrieb Qu Wenruo: Did you get the half way send stream? Luckily, yes! If the send stream has something, please use "--no-data" option to send the subvolume again to get the metadata only dump, and upload it for

RE: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

Hi, Qu Wenruo > From: Qu Wenruo [mailto:quwen...@cn.fujitsu.com] > Sent: Monday, September 05, 2016 3:57 PM > To: Zhao Lei ; 'Sean Fu' ; > dste...@suse.com > Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com; > linux-btrfs@vger.kernel.org;

Re: btrfs send extremely slow (almost stuck)

Oliver Freyermuth posted on Mon, 05 Sep 2016 23:29:08 +0200 as excerpted: > However, you gave me an idea. I had a look at the output of running the > file created by "btrfs send --no-data" piping that through "strings". > This revealed the last files which btrfs send was able to treat before >

Re: [PATCH 1/3] btrfs-progs: Introduce new send-dump object

At 08/24/2016 08:49 PM, David Sterba wrote: On Wed, Aug 17, 2016 at 08:42:48AM +0800, Qu Wenruo wrote: At 08/16/2016 10:31 PM, David Sterba wrote: On Mon, Aug 01, 2016 at 02:29:42PM +0800, Qu Wenruo wrote: Introduce send-dump.[ch] which implements a new btrfs_send_ops to exam and output

Re: btrfs send extremely slow (almost stuck)

Am 05.09.2016 um 07:21 schrieb Qu Wenruo: > Did you get the half way send stream? Luckily, yes! > If the send stream has something, please use "--no-data" option to send the > subvolume again to get the metadata only dump, and upload it for debug. Also the metadata-only dump fails with the

[PATCH]btrfs-progs: Post btrfs-convert verify permissions and acls

Signed-off-by: Lakshmipathi.G --- tests/common.convert | 95 +++- 1 file changed, 94 insertions(+), 1 deletion(-) diff --git a/tests/common.convert b/tests/common.convert index 4e3d49c..67c99b1 100644 ---

Re: [PATCH 1/2] btrfs-progs: mkfs: Warn user for minimal RAID5/6 devices setup

On Fri, Sep 02, 2016 at 11:59:07AM +1000, Steven Haigh wrote: > Is it worthwhile adding a note that RAID5 / RAID6 may very well eat your > data at this stage? This depends on the kernel implementation, so it needs to take that into account. There's a patchset in the works to automatically select

Re: [PATCH 0/7] Kill the btree inode

On Fri, Sep 02, 2016 at 03:39:59PM -0400, Josef Bacik wrote: > In order to provide a better way to do subpage blocksizes we need to stop > allocating pages from a per fs btree inode and instead allocate our own pages. > This work depends on 3 generic patches that I've sent previously > > remove

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

On Fri, Sep 2, 2016 at 8:35 PM, Liu Bo wrote: > This can only happen with CONFIG_BTRFS_FS_CHECK_INTEGRITY=y. > > Commit 1ba98d0 ("Btrfs: detect corruption when non-root leaf has zero item") > assumes that a leaf is its root when leaf->bytenr == btrfs_root_bytenr(root), >

Re: [PATCH] Btrfs: don't leak reloc root nodes on error

On Fri, Sep 02, 2016 at 06:08:35PM -0700, Liu Bo wrote: > On Fri, Sep 02, 2016 at 03:25:43PM -0400, Josef Bacik wrote: > > We don't track the reloc roots in any sort of normal way, so the only way > > the > > root/commit_root nodes get free'd is if the relocation finishes > > successfully and >

Re: gazillions of Incorrect local/global backref count

On Mon, 2016-09-05 at 09:27 +0200, David Sterba wrote: > As others replied, it's a false positive. There's a fix on the way, > once > it's done I'll release 4.7.2. Yeah... thanks again for confirming... and sorry that I've missed the obvious earlier post :-/ Best wishes, Chris. smime.p7s

Re: Security implications of btrfs receive?

Graham Cobb posted on Mon, 05 Sep 2016 10:59:30 +0100 as excerpted: > Lastly, even if receive is designed to be very secure, it is possible > that it could trigger/use code paths in the btrfs kernel code which are > not normally used during normal file operations and so could trigger > bugs not

Btrfs progs release 4.7.2

Hi, btrfs-progs 4.7 have been released. There's one notable fix, for the false warning from checker about backref mismatches, first reported by Chris Murphy (https://bugzilla.kernel.org/show_bug.cgi?id=155791). Update to 4.7.2 is required before using --repair. The other part are current fixes

Security implications of btrfs receive?

Does anyone know of a security analysis of btrfs receive? I assume that just using btrfs receive requires root (is that so?). But I was thinking of setting up a backup server which would receive snapshots from various client systems, each in their own path, and I wondered how much the security

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

Just like what Wang has mentioned, would you please paste all the output of the contents of /sys/fs/btrfs//allocation? It's recommended to use "grep . -IR " to get all the data as it will show the file name. Thanks, Qu At 09/03/2016 03:25 AM, Ronan Arraes Jardim Chagas wrote: Hi guys!

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

At 09/05/2016 09:19 AM, Zhao Lei wrote: Hi, Sean Fu From: Sean Fu [mailto:fxinr...@gmail.com] Sent: Sunday, September 04, 2016 7:54 PM To: dste...@suse.com Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com; zhao...@cn.fujitsu.com; linux-btrfs@vger.kernel.org;

Re: does btrfs-receive use/compare the checksums from the btrfs-send side?

At 09/04/2016 12:29 PM, Christoph Anton Mitterer wrote: On Mon, 2016-08-29 at 16:25 +0800, Qu Wenruo wrote: Send will generate checksum for each command. What does "command" mean here? Or better said how much data is secured with one CRC32? Command is one send command stream, containing

Re: gazillions of Incorrect local/global backref count

On Sun, Sep 04, 2016 at 06:50:53AM +0200, Christoph Anton Mitterer wrote: > Hey. > > I just did a btrfs check on my notebooks root fs, with: > $ uname -a > Linux heisenberg 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28) > x86_64 GNU/Linux > $ btrfs --version > btrfs-progs v4.7.1 As others

[PATCH] fstests: common: Enhance _exclude_scratch_mount_option to handle multiply options and generic fs type

Enhance _exclude_scratch_mount_option() function to get real mount options from $MOUNT_OPTIONS. Now it can understand and extract real mount option from string like "-o opt1,opt2 -oopt3". Furthermore, it doesn't use grep method, which can lead to false alert for options like inode_cache and