For raid5 it's different. No single chunks are created while copying
files to a degraded volume.
And the scrub produces very noisy kernel messages. Looks like there's
a message for each missing block (or stripe?), thousands per file. And
also many uncorrectable errors like this:
[267466.792060] f
On Sat, Apr 02, 2016 at 09:30:48AM +0800, Anand Jain wrote:
> Hot replace / auto replace is important volume manager feature
> and is critical to the data center operations, so that the degraded
> volume can be brought back to a healthy state at the earliest and
> without manual intervention.
>
>
Hi Linus
We have some fixes queued up in my for-linus-4.6 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.6
These are bug fixes, including a really old fsync bug, and a few
trace points to help us track down problems in the quota code.
Mark Fasheh (2) co
On Fri, Apr 8, 2016 at 1:27 PM, Austin S. Hemmelgarn
wrote:
> On 2016-04-08 14:30, Chris Murphy wrote:
>>
>> On Fri, Apr 8, 2016 at 12:18 PM, Austin S. Hemmelgarn
>> wrote:
>>>
>>> On 2016-04-08 14:05, Chris Murphy wrote:
On Fri, Apr 8, 2016 at 5:29 AM, Austin S. Hemmelgarn
w
Roman Mamedov posted on Fri, 08 Apr 2016 16:53:32 +0500 as excerpted:
> It's not in 4.4.6 either. I don't know why it doesn't get included, or
> what we need to do. Last time I asked, it was queued:
> http://www.spinics.net/lists/linux-btrfs/msg52478.html But maybe that
> meant 4.5 or 4.6 only? Wh
On Fri, Apr 08, 2016 at 03:23:28PM -0400, Austin S. Hemmelgarn wrote:
> On 2016-04-08 12:17, Chris Murphy wrote:
>
> I would personally suggest adding a per-filesystem node in sysfs to handle
> both 2 and 5. Having it open tells BTRFS to not automatically attempt
> countermeasures when degraded, s
On 2016-04-08 14:30, Chris Murphy wrote:
On Fri, Apr 8, 2016 at 12:18 PM, Austin S. Hemmelgarn
wrote:
On 2016-04-08 14:05, Chris Murphy wrote:
On Fri, Apr 8, 2016 at 5:29 AM, Austin S. Hemmelgarn
wrote:
I entirely agree. If the fix doesn't require any kind of decision to be
made other tha
On 2016-04-08 12:17, Chris Murphy wrote:
On Fri, Apr 8, 2016 at 5:29 AM, Austin S. Hemmelgarn
wrote:
I entirely agree. If the fix doesn't require any kind of decision to be
made other than whether to fix it or not, it should be trivially fixable
with the tools. TBH though, this particular is
Dear Sir.
I bring you greetings. My name is Mr.Oliver Seno Lim, I am a staff of Abbey
National Plc. London and heading our regional office in West Africa. Our late
customer named Engr.Ben W.westland, made a fixed deposit amount of
US$7Million.He did not declare any next of kin in any of his pap
On Fri, Apr 08, 2016 at 03:10:35PM +0200, Holger Hoffstätte wrote:
> [cc: Mark and Qu]
>
> On 04/08/16 13:51, Holger Hoffstätte wrote:
> > On 04/08/16 13:14, Filipe Manana wrote:
> >> Using Chris' for-linus-4.6 branch, which is 4.5-rc6 + all 4.6 btrfs
> >> patches, it didn't reproduce here:
> >
>
johnathan falk gmail.com> writes:
>
> The drive mounts perfectly fine when you mount RO, but when you mount
> it rw it gives this (and eventually locks up the system as I can't
> restart it cleanly):
>
> kernel: BTRFS info (device sdb1): disk space caching is enabled
> Apr 06 17:09:16 kernel: B
On Fri, Apr 8, 2016 at 12:18 PM, Austin S. Hemmelgarn
wrote:
> On 2016-04-08 14:05, Chris Murphy wrote:
>>
>> On Fri, Apr 8, 2016 at 5:29 AM, Austin S. Hemmelgarn
>> wrote:
>>
>>> I entirely agree. If the fix doesn't require any kind of decision to be
>>> made other than whether to fix it or not
On 2016-04-08 14:05, Chris Murphy wrote:
On Fri, Apr 8, 2016 at 5:29 AM, Austin S. Hemmelgarn
wrote:
I entirely agree. If the fix doesn't require any kind of decision to be
made other than whether to fix it or not, it should be trivially fixable
with the tools. TBH though, this particular is
On Fri, Apr 8, 2016 at 5:29 AM, Austin S. Hemmelgarn
wrote:
> I entirely agree. If the fix doesn't require any kind of decision to be
> made other than whether to fix it or not, it should be trivially fixable
> with the tools. TBH though, this particular issue with devices disappearing
> and re
pshot around, it suggests you
need more space. Otherwise the minimal strategy is:
Yesterday's source has subvols:
root.current
root.20160406
So you'd do
btrfs sub snap -r root.current root.20160407
btrfs send -p root.20160406 root.20160407 | btrfs receive xxx
btrfs sub del root.20
On Fri, Apr 8, 2016 at 1:01 PM, Martin Steigerwald wrote:
> Hello!
>
> As far as I understood, for differential btrfs send/receive – I didn´t use it
> yet – I need to keep a snapshot on the source device to then tell btrfs send
> to send the differences between the snapshot and the current state.
On Fri, Apr 8, 2016 at 5:29 AM, Austin S. Hemmelgarn
wrote:
>> I can see this being happening automatically with up to 2 device
>> failures, so that all subsequent writes are fully intact stripe
>> writes. But the instant there's a 3rd device failure, there's a rather
>> large hole in the file sy
On 2016-04-08 20:53, Roman Mamedov wrote:
> Do you snapshot the parent subvolume which holds the databases? Can you
> correlate that perhaps ENOSPC occurs at the time of snapshotting? If
> yes, then
> you should try the patch https://patchwork.kernel.org/patch/7967161/
>
> (Too bad this was not
On Freitag, 8. April 2016 11:12:54 CEST Hugo Mills wrote:
> On Fri, Apr 08, 2016 at 01:01:03PM +0200, Martin Steigerwald wrote:
> > Hello!
> >
> > As far as I understood, for differential btrfs send/receive – I didn´t use
> > it yet – I need to keep a snapshot on the source device to then tell
> >
[cc: Mark and Qu]
On 04/08/16 13:51, Holger Hoffstätte wrote:
> On 04/08/16 13:14, Filipe Manana wrote:
>> Using Chris' for-linus-4.6 branch, which is 4.5-rc6 + all 4.6 btrfs
>> patches, it didn't reproduce here:
>
> Great, that's good to know (sort of :). Thanks also to Liu Bo.
>
>> Are you sur
On Fri, 08 Apr 2016 20:36:26 +0900
Tomasz Chmielewski wrote:
> On 2016-02-08 20:24, Roman Mamedov wrote:
>
> >> Linux 4.4.0 - btrfs is mainly used to host lots of test containers,
> >> often snapshots, and at times, there is heavy IO in many of them for
> >> extended periods of time. btrfs is on
On 04/08/16 13:14, Filipe Manana wrote:
> Using Chris' for-linus-4.6 branch, which is 4.5-rc6 + all 4.6 btrfs
> patches, it didn't reproduce here:
Great, that's good to know (sort of :). Thanks also to Liu Bo.
> Are you sure that you are not using some patches not in 4.6?
Quite a few, but to off
On 2016-02-08 20:24, Roman Mamedov wrote:
Linux 4.4.0 - btrfs is mainly used to host lots of test containers,
often snapshots, and at times, there is heavy IO in many of them for
extended periods of time. btrfs is on HDDs.
Every few days I'm getting "no space left" in a container running
mong
On 2016-04-07 15:32, Chris Murphy wrote:
On Thu, Apr 7, 2016 at 5:19 AM, Austin S. Hemmelgarn
wrote:
On 2016-04-06 19:08, Chris Murphy wrote:
On Wed, Apr 6, 2016 at 9:34 AM, Ank Ular wrote:
From the ouput of 'dmesg', the section:
[ 20.998071] BTRFS: device label FSgyroA devid 9 transi
On Thu, Apr 7, 2016 at 5:44 PM, Holger Hoffstätte
wrote:
> Hi,
>
> Looks like I just found an exciting new corner case.
> kernel 4.4.6 with btrfs ~4.6, so 4.6 should reproduce.
Using Chris' for-linus-4.6 branch, which is 4.5-rc6 + all 4.6 btrfs
patches, it didn't reproduce here:
#!/bin/bash
dme
On Fri, Apr 08, 2016 at 01:01:03PM +0200, Martin Steigerwald wrote:
> Hello!
>
> As far as I understood, for differential btrfs send/receive – I didn´t use it
> yet – I need to keep a snapshot on the source device to then tell btrfs send
> to send the differences between the snapshot and the cur
Hello!
As far as I understood, for differential btrfs send/receive – I didn´t use it
yet – I need to keep a snapshot on the source device to then tell btrfs send
to send the differences between the snapshot and the current state.
Now the BTRFS filesystems on my SSDs are often quite full, thus I
There were reports about heavy stack use by
recursive calling .bi_end_io().[1][2][3]
Also these patches[1] [2] [3] were posted for
addressing the issue. And the idea is basically
similar, all serializes the recursive calling
of .bi_end_io() by percpu list.
This patch still takes the same idea, bu
28 matches
Mail list logo
