Re: btrfs send extremely slow (almost stuck)

At 09/05/2016 05:41 AM, Oliver Freyermuth wrote: Am 30.08.2016 um 02:48 schrieb Qu Wenruo: Yes. And more specifically, it doesn't even affect delta backup. For shared extents caused by reflink/dedupe(out-of-band or even incoming in-band), it will be send as individual files. For contents,

Re: [PATCH] btrfs: let btrfs_delete_unused_bgs() to clean relocated bgs

2016-09-02 (金) の 09:35 -0400 に Josef Bacik さんは書きました: > On 09/02/2016 03:46 AM, Naohiro Aota wrote: > > > > Currently, btrfs_relocate_chunk() is removing relocated BG by > > itself. But > > the work can be done by btrfs_delete_unused_bgs() (and it's better > > since it > > trim the BG). Let's

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

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; > linux-ker...@vger.kernel.org; Sean Fu

Re: gazillions of Incorrect local/global backref count

On Sat, Sep 3, 2016 at 10:50 PM, 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 >

Re: Re[4]: btrfs check "Couldn't open file system" after error in transaction.c

On Sun, Sep 4, 2016 at 1:23 PM, Hendrik Friedel wrote: > Hello, > > here the output of btrfsck: > Checking filesystem on /dev/sdd > UUID: a8af3832-48c7-4568-861f-e80380dd7e0b > checking extents > checking free space cache > checking fs root > checking csums > checking root

Re: Re[3]: btrfs check "Couldn't open file system" after error in transaction.c

On Sun, Sep 4, 2016 at 12:51 PM, Hendrik Friedel wrote: > Hello again, > > before overwriting the filesystem, some last questions: > >>> Maybe >>> take advantage of the fact it does read only and recreate it. You >>> could take a btrfs-image and btrfs-debug-tree first, >>

Re: Re[2]: btrfs check "Couldn't open file system" after error in transaction.c

Lost track of this...sorry. On Sun, Aug 28, 2016 at 12:04 PM, Hendrik Friedel wrote: > Hi Chris, > > thanks for your reply -especially on a Sunday. >>> >>> I have a filesystem (three disks with no raid) >> >> >> So it's data single *and* metadata single? >> > No: > Data,

Re: btrfs send extremely slow (almost stuck)

Am 30.08.2016 um 02:48 schrieb Qu Wenruo: > Yes. > And more specifically, it doesn't even affect delta backup. > > For shared extents caused by reflink/dedupe(out-of-band or even incoming > in-band), it will be send as individual files. > > For contents, they are all the same, just more space

Re[4]: btrfs check "Couldn't open file system" after error in transaction.c

Hello, here the output of btrfsck: Checking filesystem on /dev/sdd UUID: a8af3832-48c7-4568-861f-e80380dd7e0b checking extents checking free space cache checking fs root checking csums checking root refs checking quota groups Ignoring qgroup relation key 24544 Ignoring qgroup relation key 24610

Re[3]: btrfs check "Couldn't open file system" after error in transaction.c

Hello again, before overwriting the filesystem, some last questions: Maybe take advantage of the fact it does read only and recreate it. You could take a btrfs-image and btrfs-debug-tree first, And what do I do with it? because there's some bug somewhere: somehow it became inconsistent,

Re: OOM killer and Btrfs

On Sun, Sep 4, 2016, at 12:06, Markus Trippelsdorf wrote: > On 2016.09.04 at 11:59 +0200, Francesco Turco wrote: > > Is the problem already known? Should I report a bug? Is there a patch I > > can try? Thanks. > > This issue was recently fixed by: > > commit

Re: OOM killer and Btrfs

On 2016.09.04 at 11:59 +0200, Francesco Turco wrote: > I use Btrfs on a Gentoo Linux system with kernel 4.7.2. When my computer > is under heavy I/O load some application often crashes, for example > ClamAV, Firefox or Portage. I suspect the problem is due to Btrfs, but I > may be wrong. > >

OOM killer and Btrfs

I use Btrfs on a Gentoo Linux system with kernel 4.7.2. When my computer is under heavy I/O load some application often crashes, for example ClamAV, Firefox or Portage. I suspect the problem is due to Btrfs, but I may be wrong. These are the most recent error messages from journalctl, but I have

Re: gazillions of Incorrect local/global backref count

On Sun, 2016-09-04 at 05:33 +, Paul Jones wrote: > The errors are wrong. I nearly ruined my filesystem a few days ago by > trying to repair similar errors, thankfully all seems ok. > Check again with btrfs-progs 4.6.1 and see if the errors go away, > mine did. > See open bug