Re: btrfs issue with mariadb incremental backup

On Sat, Aug 12, 2017 at 9:40 PM, wrote: > [root@backuplogC7 ~]# rsync -avnc /var/lib/mariadb/mysql_201708090830/ > root@192.168.45.166://var/lib/mariadb/mysql_201708090830/ > sending incremental file list > ./ > ib_logfile1 > ibdata1 > > sent 3779 bytes received 25 bytes

[PATCH 3/4] btrfs: decode compress type for tracing

So with this now we see the compression type in string. Signed-off-by: Anand Jain --- include/trace/events/btrfs.h | 25 - 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h

[PATCH 2/4] btrfs: convert enum btrfs_compression_type to define

There isn't a huge list to manage the types, which can be managed with defines. It helps to easily print the types in tracing as well. Signed-off-by: Anand Jain --- fs/btrfs/compression.h | 7 --- fs/btrfs/super.c| 2 +-

[PATCH 1/4] btrfs: remove unused BTRFS_COMPRESS_LAST

We aren't using this define, so removing it. Signed-off-by: Anand Jain --- fs/btrfs/compression.h | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/btrfs/compression.h b/fs/btrfs/compression.h index 87f6d3332163..e749df6dd39a 100644 --- a/fs/btrfs/compression.h +++

[PATCH 4/4 v3] btrfs: add compression trace points

From: Anand Jain This patch adds compression and decompression trace points for the purpose of debugging. Signed-off-by: Anand Jain Reviewed-by: Nikolay Borisov --- v3: . Rename to a simple names, without worrying about being

[PATCH 0/4] misc compression tracing related patches

Anand Jain (4): btrfs: remove unused BTRFS_COMPRESS_LAST btrfs: convert enum btrfs_compression_type to define btrfs: decode compress type for tracing btrfs: add compression trace points fs/btrfs/compression.c | 11 +++ fs/btrfs/compression.h | 8 --

[PATCH] btrfs: use BTRFS_FSID_SIZE for fsid

We have define for FSID size so use it. Signed-off-by: Anand Jain --- include/trace/events/btrfs.h | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h index

Re: btrfs issue with mariadb incremental backup

Hi Chris, I started as your suggestion again. The diff occured since snapshot mysql_201708090830 manually send. What should I do next? - delete all the bad/mismatching snapshots only on the destination computer. [root@joytest ~]# date Sun Aug 13 10:27:23 ICT 2017 [root@joytest ~]# cd

Re: btrfs issue with mariadb incremental backup

On Sat, Aug 12, 2017 at 8:20 PM, wrote: > [root@backuplogC7 ~]# rsync -avnc /var/lib/mariadb/mysql_201708090830 > root@192.168.45.166://var/lib/mariadb/mysql_201708090830 You need trailing / for the first directory with -a option. rsync -a dir dir is not the same

Re: btrfs issue with mariadb incremental backup

Hi Chris, I did as you suggest and the result was bad then I decided to start over with snapshot mysql_201708070830 and manually send incremental the result rsync always said "a log diff" but the dest can start mariadb until snapshot "mysql_201708100830" it couldn't start mariadb. The

Re: btrfs issue with mariadb incremental backup

On Sat, Aug 12, 2017 at 4:49 PM, Hugo Mills wrote: > On Sat, Aug 12, 2017 at 03:34:01PM -0600, Chris Murphy wrote: >> On Fri, Aug 11, 2017 at 11:08 PM, wrote: >> >> >> > The backup script has the btrfs sync command since Aug 3 >> >> >> From your script:

Re: btrfs issue with mariadb incremental backup

On Sat, Aug 12, 2017 at 4:41 PM, Janos Toth F. wrote: > On Sat, Aug 12, 2017 at 11:34 PM, Chris Murphy > wrote: >> On Fri, Aug 11, 2017 at 11:08 PM, wrote: >> >> I think the problem is that the script does things so fast

Re: btrfs issue with mariadb incremental backup

On Sat, Aug 12, 2017 at 03:34:01PM -0600, Chris Murphy wrote: > On Fri, Aug 11, 2017 at 11:08 PM, wrote: > > > > The backup script has the btrfs sync command since Aug 3 > > > From your script: > > system btrfs sub snap -r $basepath $snappath > > system btrfs sub sync

Re: btrfs issue with mariadb incremental backup

On Sat, Aug 12, 2017 at 11:34 PM, Chris Murphy wrote: > On Fri, Aug 11, 2017 at 11:08 PM, wrote: > > I think the problem is that the script does things so fast that the > snapshot is not always consistent on disk before btrfs send starts. > It's

Re: btrfs issue with mariadb incremental backup

On Fri, Aug 11, 2017 at 11:08 PM, wrote: > The backup script has the btrfs sync command since Aug 3 >From your script: > system btrfs sub snap -r $basepath $snappath > system btrfs sub sync $basepath >From the man page: sync [subvolid...] Wait until given

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On Sat, Aug 12, 2017 at 01:51:46PM +0200, Christoph Anton Mitterer wrote: > On Sat, 2017-08-12 at 00:42 -0700, Christoph Hellwig wrote: > > And how are you going to write your data and checksum atomically when > > doing in-place updates? > > Maybe I misunderstand something, but what's the big

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On Sat, 2017-08-12 at 00:42 -0700, Christoph Hellwig wrote: > And how are you going to write your data and checksum atomically when > doing in-place updates? Maybe I misunderstand something, but what's the big deal with not doing it atomically (I assume you mean in terms of actually writing to

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On Sat, Aug 12, 2017 at 02:10:18AM +0200, Christoph Anton Mitterer wrote: > Qu Wenruo wrote: > >Although Btrfs can disable data CoW, nodatacow also disables data  > >checksum, which is another main feature for btrfs. > > Then decoupling of the two should probably decoupled and support for >