Re: [PATCH V2] Btrfs: keep dropped roots in cache until transaction commit

On 09/15/15 21:15, Josef Bacik wrote: > On 09/15/2015 03:08 PM, Holger Hoffstätte wrote: >> On 09/15/15 17:50, Holger Hoffstätte wrote: >>> This V2 does indeed seem to fix the issues I reported with snapshot >>> deletion & concurrent sync. I've now created/filled/deleted countless >>> snapshots

[PATCH v2 0/2] btrfs-progs: Introduce warning and error for common use

Current code use fprintf(stderr, "...") to output warnning and error information. The error message have different style, as: # grep fprintf *.c fprintf(stderr, "Open ctree failed\n"); fprintf(stderr, "%s: open ctree failed\n", __func__); fprintf(stderr, "ERROR: cannot open ctree\n"); ...

[PATCH] Btrfs: Check metadata redundancy on balance

It was recommended that I resend after the merge window. No changes since last version. Currently BTRFS allows you to make bad choices of data and metadata levels. For example -d raid1 -m raid0 means you can only use half your total disk space, but will loose everything if 1 disk fails. It

[PATCH v2 1/2] btrfs-progs: Introduce warning and error for common use

Current code use fprintf(stderr, "...") to output warnning and error information. The error message have different style, as: # grep fprintf *.c fprintf(stderr, "Open ctree failed\n"); fprintf(stderr, "%s: open ctree failed\n", __func__); fprintf(stderr, "ERROR: cannot open ctree\n"); ...

[PATCH v2 2/2] btrfs-progs: use common warning/error for cmds-scrub.c

Use common warning/error functions in cmds-scrub.c, it can make message format unified and make code simple. Signed-off-by: Qu Wenruo Signed-off-by: Zhao Lei --- cmds-scrub.c | 171 +-- 1

Re: Recovery possible on asynchronous transid ?

Am 15.09.2015 um 17:55 schrieb Hugo Mills: > On Tue, Sep 15, 2015 at 04:22:08PM +0200, Juergen Sauer wrote: >> Due an hibernation event my BTRFS Raid56 failed and is not mountable >> anymore. :( >> For Debugging I moved the Devices to an test-hardware and booted this >> system from an Arch Linux

RE: BTRFS as image store for KVM?

> -Original Message- > From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs- > ow...@vger.kernel.org] On Behalf Of Brendan Heading > Sent: Wednesday, 16 September 2015 9:36 PM > To: Duncan <1i5t5.dun...@cox.net> > Cc: linux-btrfs@vger.kernel.org > Subject: Re: BTRFS as image store

RE: [PATCH] Btrfs: Check metadata redundancy on balance

Hi, sam tygier > -Original Message- > From: linux-btrfs-ow...@vger.kernel.org > [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of sam tygier > Sent: Wednesday, September 16, 2015 4:42 PM > To: linux-btrfs@vger.kernel.org > Subject: [PATCH] Btrfs: Check metadata redundancy on balance

Re: BTRFS as image store for KVM?

On 2015-09-16 07:35, Brendan Heading wrote: Btrfs has two possible solutions to work around the problem. The first one is the autodefrag mount option, which detects file fragmentation during the write and queues up the affected file for a defragmenting rewrite by a lower priority worker thread.

Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance

Le 2015-09-16 07:02, Duncan a écrit : Stéphane Lesimple posted on Tue, 15 Sep 2015 23:47:01 +0200 as excerpted: Le 2015-09-15 16:56, Josef Bacik a écrit : On 09/15/2015 10:47 AM, Stéphane Lesimple wrote: I've been experiencing repetitive "kernel BUG" occurences in the past few days trying

Re: BTRFS as image store for KVM?

> Btrfs has two possible solutions to work around the problem. The first > one is the autodefrag mount option, which detects file fragmentation > during the write and queues up the affected file for a defragmenting > rewrite by a lower priority worker thread. This works best on the small > end,

Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance

On 09/16/15 12:28, Stéphane Lesimple wrote: > Nice to know that this bug was already somewhat known, but I can > confirm that it actually doesn't come from an ext4 conversion on my > case. In that case the "crossing stripe boundary" messages are false positives in btrfs-progs-4.2:

Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance

Le 2015-09-16 12:46, Holger Hoffstätte a écrit : On 09/16/15 12:28, Stéphane Lesimple wrote: Nice to know that this bug was already somewhat known, but I can confirm that it actually doesn't come from an ext4 conversion on my case. In that case the "crossing stripe boundary" messages are

Re: [PATCH V2] Btrfs: keep dropped roots in cache until transaction commit

On 09/16/2015 04:58 AM, Holger Hoffstätte wrote: On 09/15/15 21:15, Josef Bacik wrote: On 09/15/2015 03:08 PM, Holger Hoffstätte wrote: On 09/15/15 17:50, Holger Hoffstätte wrote: This V2 does indeed seem to fix the issues I reported with snapshot deletion & concurrent sync. I've now

Re: [PATCH V2] Btrfs: keep dropped roots in cache until transaction commit

On 09/16/15 15:50, Josef Bacik wrote: > On 09/16/2015 04:58 AM, Holger Hoffstätte wrote: >> On 09/15/15 21:15, Josef Bacik wrote: >>> On 09/15/2015 03:08 PM, Holger Hoffstätte wrote: On 09/15/15 17:50, Holger Hoffstätte wrote: > This V2 does indeed seem to fix the issues I reported with

[PATCH[ btrfs: advertise which crc32c implementation is being used on mount

Since several architectures support hardware-accelerated crc32c calculation, it would be nice to confirm that btrfs is actually using it. We can see an elevated use count for the module, but it doesn't actually show who the users are. This patch simply prints the name of the driver after

Re: [PATCH V2] Btrfs: keep dropped roots in cache until transaction commit

>On 09/15/15 21:15, Josef Bacik wrote: >> On 09/15/2015 03:08 PM, Holger Hoffstätte wrote: >>> On 09/15/15 17:50, Holger Hoffstätte wrote: This V2 does indeed seem to fix the issues I reported with snapshot deletion & concurrent sync. I've now created/filled/deleted countless

Re: [PATCH V2] Btrfs: keep dropped roots in cache until transaction commit

Hi Glyn :) On 09/16/15 16:31, Glyn Normington wrote: > We are seeing a very similar problem fwiw. Unfortunately we can't > reproduce this reliably, but it is cropping up regularly. Here's a > chore we are using to track our work on this: [2]. > > Here's the kernel log: > > [610194.395845]

FYIO: A rant about btrfs

Hello, just for information. I stumbled about a rant about btrfs-performance: http://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp MfG bmg -- „Des is völlig wurscht, was heut beschlos- | M G Berberich sen wird: I bin sowieso dagegn!“ |

Re: FYIO: A rant about btrfs

On 2015-09-16 10:43, M G Berberich wrote: Hello, just for information. I stumbled about a rant about btrfs-performance: http://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp MfG bmg It is worth noting a few things that were done incorrectly in this

Re: FYIO: A rant about btrfs

Hi, 2015-09-16 17:20 GMT+02:00 Austin S Hemmelgarn : [...] > 3. He's testing it for a workload is a known and documented problem for > BTRFS, and claiming that that means that it isn't worth considering as a > general usage filesystem. Most people don't run RDBMS servers on

Re: FYIO: A rant about btrfs

Hi, > On Sep 16, 2015, at 11:20 AM, Austin S Hemmelgarn > wrote: > > On 2015-09-16 10:43, M G Berberich wrote: >> Hello, >> >> just for information. I stumbled about a rant about btrfs-performance: >> >>

Re: FYIO: A rant about btrfs

Some response to your criticism: 1. How would that hole fare with a fully battery-backed/flash-backed path (battery-backed or flash-backed HBA with disks with full power-loss protection, like the Intel S3500)? In such a situation (quite commonplace in server-land), power-loss should not cause

Re: FYIO: A rant about btrfs

On 2015-09-16 12:45, Martin Tippmann wrote: Hi, 2015-09-16 17:20 GMT+02:00 Austin S Hemmelgarn : [...] 3. He's testing it for a workload is a known and documented problem for BTRFS, and claiming that that means that it isn't worth considering as a general usage

Re: FYIO: A rant about btrfs

On 2015-09-16 12:51, Vincent Olivier wrote: Hi, On Sep 16, 2015, at 11:20 AM, Austin S Hemmelgarn wrote: On 2015-09-16 10:43, M G Berberich wrote: Hello, just for information. I stumbled about a rant about btrfs-performance:

Re: FYIO: A rant about btrfs

> On Sep 16, 2015, at 2:22 PM, Austin S Hemmelgarn wrote: > > On 2015-09-16 12:51, Vincent Olivier wrote: >> Hi, >> >> >>> On Sep 16, 2015, at 11:20 AM, Austin S Hemmelgarn >>> wrote: >>> >>> On 2015-09-16 10:43, M G Berberich wrote: Hello,

Re: FYIO: A rant about btrfs

On 2015-09-16 12:25, Zia Nayamuth wrote: Some response to your criticism: 1. How would that hole fare with a fully battery-backed/flash-backed path (battery-backed or flash-backed HBA with disks with full power-loss protection, like the Intel S3500)? In such a situation (quite commonplace in

Re: FYIO: A rant about btrfs

On 2015-09-16 15:04, Vincent Olivier wrote: On Sep 16, 2015, at 2:22 PM, Austin S Hemmelgarn wrote: On 2015-09-16 12:51, Vincent Olivier wrote: Hi, On Sep 16, 2015, at 11:20 AM, Austin S Hemmelgarn wrote: On 2015-09-16 10:43, M G Berberich

Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance

Le 2015-09-16 22:18, Duncan a écrit : Stéphane Lesimple posted on Wed, 16 Sep 2015 15:04:20 +0200 as excerpted: Le 2015-09-16 12:46, Holger Hoffstätte a écrit : I also disabled quota because it has almost for sure nothing to do with the bug, and now btrsfck is 100% happy: Yes. Quotas

Re: FYIO: A rant about btrfs

Vincent Olivier posted on Wed, 16 Sep 2015 15:04:38 -0400 as excerpted: 3. He's testing it for a workload is a known and documented problem for BTRFS, and claiming that that means that it isn't worth considering as a general usage filesystem. Most people don't run RDBMS

Re: FYIO: A rant about btrfs

On Wed, Sep 16, 2015 at 03:04:38PM -0400, Vincent Olivier wrote: > > On Sep 16, 2015, at 2:22 PM, Austin S Hemmelgarn > > wrote: > > On 2015-09-16 12:51, Vincent Olivier wrote: > >>> On Sep 16, 2015, at 11:20 AM, Austin S Hemmelgarn > >>> wrote: >

Re: FYIO: A rant about btrfs

On Wed, Sep 16, 2015 at 03:21:26PM -0400, Austin S Hemmelgarn wrote: > On 2015-09-16 12:45, Martin Tippmann wrote: > >2015-09-16 17:20 GMT+02:00 Austin S Hemmelgarn : > >[...] [...] > > From reading the list I understand that btrfs is still very much work > >in progress and

Re: FYIO: A rant about btrfs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Sep 16, 2015 at 03:08:43PM -0400, Austin S Hemmelgarn wrote: > On 2015-09-16 12:25, Zia Nayamuth wrote: > >Some response to your criticism: > > > >1. How would that hole fare with a fully battery-backed/flash-backed > >path (battery-backed or

RAID1 storage server won't boot with one disk missing

Good afternoon, Earlier today, I tried to set up a storage server using btrfs but ran into some problems. The goal was to use two disks (4.0TB each) in a raid1 configuration. What I did: 1. Attached a single disk to a regular PC configured to boot with UEFI. 2. Booted from a thumb drive that had

Re: [PATCH 1/2] btrfs: Do per-chunk degrade mode check at mount time

To Anand Jain, Any feedback on this method to allow single chunk still be degraded mountable? It should be much better than allowing degraded mount for any missing device case. Thanks, Qu Qu Wenruo wrote on 2015/09/16 11:43 +0800: Btrfs supports different raid profile for meta/data/sys,

Re: BTRFS as image store for KVM?

As others have said here, it's probably not going to work for you especially if you want to use regular scheduled btrfs snapshots on the host (which I consider to be 50% of the reason why I use btrfs in the first place). Once I had learned this lesson the hard way, I had a xen server using

Re: FYIO: A rant about btrfs

On Wed, Sep 16, 2015 at 12:45 PM, Martin Tippmann wrote: > From reading the list I understand that btrfs is still very much work > in progress and performance is not a top priority at this stage but I > don't see why it shouldn't perform at least equally good as

Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance

Stéphane Lesimple wrote on 2015/09/16 22:41 +0200: Le 2015-09-16 22:18, Duncan a écrit : Stéphane Lesimple posted on Wed, 16 Sep 2015 15:04:20 +0200 as excerpted: Le 2015-09-16 12:46, Holger Hoffstätte a écrit : I also disabled quota because it has almost for sure nothing to do with the

Re: kernel BUG at ctree.c:5196

2015-07-21 21:47 GMT+03:00 Hendrik Friedel : > Hello, > > I recently added a third device to my raid and converted it from raid0 to > raid 5 via balance (dconvert, mconvert). > Unfortunately, the new device was faulty. I wrote about this on this List in > "size 2.73TiB used