Re: Force recalculation of a data block checksum

On 24.07.2016 07:07, Andrei Borzenkov wrote: Rewriting single block in question should do it. As you can read from raw device and have both physical and logical block address something like dd if=/dev/sdd1 skip=222940168 count=8 | dd of=/path/to/dysk/dysk.bin seek=189669768 conv=notrunc count=8

Re: [BTRFS-PROGS][PATCH] Add two new commands: 'btrfs insp physical-find' and 'btrfs insp physical-dump'

At 07/26/2016 01:14 AM, Goffredo Baroncelli wrote: On 2016-07-25 04:14, Qu Wenruo wrote: Hi Goffredo, At 07/24/2016 07:03 PM, Goffredo Baroncelli wrote: Hi all, the following patches add two new commands: 1) btrfs inspect-internal physical-find 2) btrfs inspect-internal physical-dump The

Re: [PATCH RFC] btrfs: send: Disable clone detection

At 07/25/2016 11:37 PM, David Sterba wrote: On Mon, Jul 25, 2016 at 03:19:59PM +0800, Qu Wenruo wrote: This patch will disable clone detection of send. Making that unconditional is not the right way. We do have the send operation flags in place so if you really think there's a need for

Re: [PATCH RFC] btrfs: send: Disable clone detection

At 07/25/2016 09:48 PM, Filipe Manana wrote: On Mon, Jul 25, 2016 at 8:19 AM, Qu Wenruo wrote: This patch will disable clone detection of send. The main problem of clone detetion in send is its memory usage and long execution time. The clone detection is done by

Re: Any suggestions for thousands of disk image snapshots ?

On Mon, Jul 25, 2016 at 2:49 PM, Chris Murphy wrote: > 1. mdadm raid10 + LVM thinp + either XFS or Btrfs. You probably want to use LVM thin provisioning because its snapshot implementation is much faster and more hands off than thick provisioning. And you'll need to

Re: Any suggestions for thousands of disk image snapshots ?

On Mon, Jul 25, 2016 at 1:25 AM, Kurt Seo wrote: > Hi all > > > I am currently running a project for building servers with btrfs. > Purposes of servers are exporting disk images through iscsi targets > and disk images are generated from btrfs subvolume snapshot.

Re: [PATCH v2 3/4] btrfs: update btrfs_space_info's bytes_may_use timely

On 07/25/2016 03:51 AM, Wang Xiaoguang wrote: This patch can fix some false ENOSPC errors, below test script can reproduce one false ENOSPC error: #!/bin/bash dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=128 dev=$(losetup --show -f fs.img) mkfs.btrfs -f -M

Re: [BTRFS-PROGS][PATCH] Add two new commands: 'btrfs insp physical-find' and 'btrfs insp physical-dump'

On 2016-07-25 04:14, Qu Wenruo wrote: > Hi Goffredo, > > At 07/24/2016 07:03 PM, Goffredo Baroncelli wrote: >> Hi all, >> >> the following patches add two new commands: 1) btrfs >> inspect-internal physical-find 2) btrfs inspect-internal >> physical-dump >> >> The aim of these two new commands

Re: [PATCH RFC] btrfs: send: Disable clone detection

On Mon, Jul 25, 2016 at 03:19:59PM +0800, Qu Wenruo wrote: > This patch will disable clone detection of send. Making that unconditional is not the right way. We do have the send operation flags in place so if you really think there's a need for disabling the clones, let's add a flag for that

Re: [PATCH RFC] btrfs: send: Disable clone detection

On Mon, Jul 25, 2016 at 8:19 AM, Qu Wenruo wrote: > This patch will disable clone detection of send. > > The main problem of clone detetion in send is its memory usage and long > execution time. > > The clone detection is done by iterating all backrefs and adding backref

Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

On 07/25/2016 09:01 AM, David Sterba wrote: On Mon, Jul 18, 2016 at 09:42:50AM -0400, Josef Bacik wrote: This makes search for BLOCK_GROUP_ITEM very very very slow if extent tree is really big. On the handle, we search CHUNK_ITEM very very fast, because CHUNK_ITEM are in their own tree.

Re: [PATCH v2 3/4] btrfs: update btrfs_space_info's bytes_may_use timely

On 07/25/2016 03:51 AM, Wang Xiaoguang wrote: This patch can fix some false ENOSPC errors, below test script can reproduce one false ENOSPC error: #!/bin/bash dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=128 dev=$(losetup --show -f fs.img) mkfs.btrfs -f -M

Re: [PATCH v2 4/4] btrfs: should block unused block groups deletion work when allocating data space

On 07/25/2016 03:51 AM, Wang Xiaoguang wrote: cleaner_kthread() may run at any time, in which it'll call btrfs_delete_unused_bgs() to delete unused block groups. Because this work is asynchronous, it may also result in false ENOSPC error. Please see below race window: CPU1

Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

On Mon, Jul 18, 2016 at 09:42:50AM -0400, Josef Bacik wrote: > > > > This makes search for BLOCK_GROUP_ITEM very very very slow if extent tree is > > really big. > > > > On the handle, we search CHUNK_ITEM very very fast, because CHUNK_ITEM are > > in > > their own tree. > > (CHUNK_ITEM and

Re: [PATCH v12.2 03/15] btrfs: dedupe: Introduce function to initialize dedupe info

/Btrfs-In-band-De-duplication/20160725-140320 config: i386-randconfig-s0-07250950 (attached as .config) compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): fs/buil

[PATCH v2 0/4] update bytes_may_use timely to avoid false ENOSPC issue

Currently in btrfs, for data space reservation, it does not update bytes_may_use in btrfs_update_reserved_bytes() and the decrease operation will be delayed to be done in extent_clear_unlock_delalloc(), for fallocate(2), decrease operation is even delayed to be done in end of btrfs_fallocate(),

[PATCH v2 1/4] btrfs: use correct offset for reloc_inode in prealloc_file_extent_cluster()

In prealloc_file_extent_cluster(), btrfs_check_data_free_space() uses wrong file offset for reloc_inode, it uses cluster->start and cluster->end, which indeed are extent's bytenr. The correct value should be cluster->[start|end] minus block group's start bytenr. start bytenr cluster->start |

[PATCH v2 2/4] btrfs: divide btrfs_update_reserved_bytes() into two functions

This patch divides btrfs_update_reserved_bytes() into btrfs_add_reserved_bytes() and btrfs_free_reserved_bytes(), and next patch will extend btrfs_add_reserved_bytes（）to fix some false ENOSPC error, please see later patch for detailed info. Signed-off-by: Wang Xiaoguang

[PATCH v2 3/4] btrfs: update btrfs_space_info's bytes_may_use timely

This patch can fix some false ENOSPC errors, below test script can reproduce one false ENOSPC error: #!/bin/bash dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=128 dev=$(losetup --show -f fs.img) mkfs.btrfs -f -M $dev mkdir /tmp/mntpoint mount

[PATCH v2 4/4] btrfs: should block unused block groups deletion work when allocating data space

cleaner_kthread() may run at any time, in which it'll call btrfs_delete_unused_bgs() to delete unused block groups. Because this work is asynchronous, it may also result in false ENOSPC error. Please see below race window: CPU1 | CPU2

[PATCH v2] generic/371: run write(2) and fallocate(2) in parallel

Currently in btrfs, there is something wrong with fallocate(2)'s data space reservation, it'll temporarily occupy more data space thant it really needs, which in turn will impact other operations' data request. In this test case, it runs write(2) and fallocate(2) in parallel and the total needed

Any suggestions for thousands of disk image snapshots ?

Hi all I am currently running a project for building servers with btrfs. Purposes of servers are exporting disk images through iscsi targets and disk images are generated from btrfs subvolume snapshot. Maximum number of clients is 500 and each client uses two snapshots of disk images. the

[PATCH RFC] btrfs: send: Disable clone detection

This patch will disable clone detection of send. The main problem of clone detetion in send is its memory usage and long execution time. The clone detection is done by iterating all backrefs and adding backref whose root is the source. However iterating all backrefs is already quite a bad idea,

Re: [PATCH] generic/371: run write(2) and fallocate(2) in parallel

hello, On 07/21/2016 06:41 PM, Eryu Guan wrote: On Thu, Jul 21, 2016 at 03:30:25PM +0800, Wang Xiaoguang wrote: Currently in btrfs, there is something wrong with fallocate(2)'s data space reservation, it'll temporarily occupy more data space thant it really needs, which in turn will impact