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, t
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 dedup
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
> Subject: [PATCH]
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
>
>
>
> during:
> checkin
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 refs
> checking quota gr
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,
>>
>> And what do I do with
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, single: total=8.14TiB, u
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 us
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
I
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, and
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 6b4e3181d7bd5ca5ab6f45929e4a5ffa7ab4ab
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.
>
> These
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
m
13 matches
Mail list logo
