From: Zhao Lei
For example, in scrub_raid56_parity(), following lines are used
to judge is all data processed:
place1: if (key.objectid > logic_end) ...
place2: if (logic_start >= logic_end) ...
...
(place2 is typo, is should be ">", it is copied from other
place, where logic_end's meaning
On Jul 14, 2015 at 1406 +0200, David Sterba appeared and said:
> ...
> at the beginning of the output. Such filesystems must not be used and
> must be recreated. Read-only mount should be safe to retrieve the data,
> but at the moment this hasn't been verified.
I was able to copy my Btrfs filesyst
On 07/20/2015 03:29 PM, Christoph Hellwig wrote:
> Currently we have two different ways to signal an I/O error on a BIO:
>
> (1) by clearing the BIO_UPTODATE flag
> (2) by returning a Linux errno value to the bi_end_io callback
>
> The first one has the drawback of only communicating a single p
Hi Steve,
I checked your binary dump.
Previously I was too focused on the assert error, but ignored some even
larger bug...
As for the btrfs-debug-tree output, subvol 257 and 5 are completely
corrupted.
Subvol 257 seems to contains a new tree root, and 5 seems to contains a
new device tree.
Donald Pearson posted on Mon, 20 Jul 2015 08:33:47 -0500 as excerpted:
>> Also, FWIW, the btrfs quota subsystem increases snapshot management
>> complexity dramatically, so if you're using that, aim for the low ends
>> of the above recommendation if at all possible, and/or consider either
>> turni
Reviewed-by: Anand Jain
On 07/20/2015 05:55 PM, Zhaolei wrote:
From: Zhao Lei
When mount failed because missing device, we can see following
dmesg:
[ 1060.267743] BTRFS: too many missing devices, writeable mount is not allowed
[ 1060.273158] BTRFS: open_ctree failed
This patch add miss
On Tuesday 21 Jul 2015 08:12:20 Dave Chinner wrote:
> On Mon, Jul 20, 2015 at 08:55:32AM -0400, Josef Bacik wrote:
> > On 07/19/2015 07:54 PM, Dave Chinner wrote:
> > >On Fri, Jul 17, 2015 at 05:10:50PM +0530, Chandan Rajendra wrote:
> > >>On Friday 17 Jul 2015 06:16:02 Brian Foster wrote:
> > >>>O
(I was off couple of days, sorry for the delay),
On 20/07/2015 17:04, Zhao Lei wrote:
Hi, Anand Jain
-Original Message-
From: linux-btrfs-ow...@vger.kernel.org
[mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Zhao Lei
Sent: Friday, July 17, 2015 5:39 PM
To: 'Anand Jain'; linux-
On 2015-07-21 04:38, Qu Wenruo wrote:
Hi Steve,
I checked your binary dump.
Previously I was too focused on the assert error, but ignored some even
larger bug...
As for the btrfs-debug-tree output, subvol 257 and 5 are completely
corrupted.
Subvol 257 seems to contains a new tree root, and 5 s
Hi Filipe, Chris,
I did more profiling work, and I want to writeup some of the things I
noticed. Hopefully it has some value for the community.
# btrfs_transaction.dirty_pages:
This "extent_io_tree" includes every eb created by
btrfs_init_new_buffer (this is the only function that adds dirty
exte
On 14 July 2015 at 21:15, Hugo Mills wrote:
> On Tue, Jul 14, 2015 at 09:09:00PM +0200, Patrik Lundquist wrote:
>> On 14 July 2015 at 20:41, Hugo Mills wrote:
>> > On Tue, Jul 14, 2015 at 01:57:07PM +0200, Patrik Lundquist wrote:
>> >> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote
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 240.97GiB after balance".
Initially the system was very unstable when tryin
On Tue, Jul 21, 2015 at 4:15 AM, Austin S Hemmelgarn
wrote:
> On 2015-07-21 04:38, Qu Wenruo wrote:
>>
>> Hi Steve,
>>
>> I checked your binary dump.
>>
>> Previously I was too focused on the assert error, but ignored some even
>> larger bug...
>>
>> As for the btrfs-debug-tree output, subvol 257
On Tue, Jul 21, 2015 at 02:52:38PM +0800, Qu Wenruo wrote:
> Zygo Blaxell wrote on 2015/07/21 00:55 -0400:
> >An in-band dedup can avoid some of these problems, especially if it
> >intercepts writes before they make it to disk. There is no need for
> >complicated on-disk-extent-splitting algorithm
On Mon, Jul 20, 2015 at 02:56:20PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Omar reported that after commit 4fbcdf669454 ("Btrfs: fix -ENOSPC when
> finishing block group creation"), introduced in 4.2-rc1, the following
> test was failing due to exhaustion of the system array i
On Tue, Jul 21, 2015 at 04:03:17PM +0530, Chandan Rajendra wrote:
> On Tuesday 21 Jul 2015 08:12:20 Dave Chinner wrote:
> > On Mon, Jul 20, 2015 at 08:55:32AM -0400, Josef Bacik wrote:
> > > On 07/19/2015 07:54 PM, Dave Chinner wrote:
> > > >On Fri, Jul 17, 2015 at 05:10:50PM +0530, Chandan Rajendr
On 07/21/2015 08:01 PM, Dave Chinner wrote:
On Tue, Jul 21, 2015 at 04:03:17PM +0530, Chandan Rajendra wrote:
On Tuesday 21 Jul 2015 08:12:20 Dave Chinner wrote:
On Mon, Jul 20, 2015 at 08:55:32AM -0400, Josef Bacik wrote:
On 07/19/2015 07:54 PM, Dave Chinner wrote:
On Fri, Jul 17, 2015 at 05
Thanks for the feedback Duncan.
It doesn't appear to be a big deal to disable quotas so that's what
I'll do for now.
On Tue, Jul 21, 2015 at 4:29 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Donald Pearson posted on Mon, 20 Jul 2015 08:33:47 -0500 as excerpted:
>
>>> Also, FWIW, the btrfs quota sub
Change subject to reflect the core of the conversation.
Zygo Blaxell wrote on 2015/07/21 18:14 -0400:
On Tue, Jul 21, 2015 at 02:52:38PM +0800, Qu Wenruo wrote:
Zygo Blaxell wrote on 2015/07/21 00:55 -0400:
An in-band dedup can avoid some of these problems, especially if it
intercepts writes b
Steve Dainard wrote on 2015/07/21 14:07 -0700:
On Tue, Jul 21, 2015 at 4:15 AM, Austin S Hemmelgarn
wrote:
On 2015-07-21 04:38, Qu Wenruo wrote:
Hi Steve,
I checked your binary dump.
Previously I was too focused on the assert error, but ignored some even
larger bug...
As for the btrfs-de
On Wed, Jul 22, 2015 at 09:49:52AM +0800, Qu Wenruo wrote:
> Change subject to reflect the core of the conversation.
>
> Zygo Blaxell wrote on 2015/07/21 18:14 -0400:
> >On Tue, Jul 21, 2015 at 02:52:38PM +0800, Qu Wenruo wrote:
> >>Zygo Blaxell wrote on 2015/07/21 00:55 -0400:
> >There's already
On Mon, 20 Jul 2015 15:29:37 +0200 Christoph Hellwig wrote:
> Currently we have two different ways to signal an I/O error on a BIO:
>
> (1) by clearing the BIO_UPTODATE flag
> (2) by returning a Linux errno value to the bi_end_io callback
>
> The first one has the drawback of only communicati
From: Zhao Lei
We need not load csum of whole strip in scrub because strip is trimed
before use, it is to say, what we really need to calculate csum is
data between [extent_logical, extent_len).
This patch changed to use above segment for btrfs_lookup_csums_range()
in scrub_stripe()
Signed-off-
From: Zhao Lei
When we access extent_root in scrub_stripe() and
scrub_raid56_parity(), we need bypass unrelated tree item firstly
before using its contents to do other condition.
It is not a bug fix, only making code sequence in logic.
Signed-off-by: Zhao Lei
---
fs/btrfs/scrub.c | 16 +++
Hello,
I met a problem when resize btrfs as follows. The btrfs related sysinfo is
attached at the end of this mail[1].
$ dd if=/dev/zero of=btrfs_5gb.img bs=1024 count=500
$ mkfs.btrfs btrfs_5gb.img
$ sudo mkdir -p /mnt/btrfs_5gb
$ mount -t btrfs btrfs_5gb.img /mnt/btrfs_5gb
$ btrf
On Tue, Jul 21, 2015 at 08:37:39PM -0400, Josef Bacik wrote:
> On 07/21/2015 08:01 PM, Dave Chinner wrote:
> >On Tue, Jul 21, 2015 at 04:03:17PM +0530, Chandan Rajendra wrote:
> >>On Tuesday 21 Jul 2015 08:12:20 Dave Chinner wrote:
> >>>On Mon, Jul 20, 2015 at 08:55:32AM -0400, Josef Bacik wrote:
>
The script below generates a stack trace, and some of the "mv dir/f dir/a"
commands that it spawns fail with the message: "Device or resource busy".
The stack trace is not generated on every iteration. The "for" loop ensures
that it is generated at least once.
Reproduced on Arch Linux, with vario
Zygo Blaxell wrote on 2015/07/21 23:49 -0400:
On Wed, Jul 22, 2015 at 09:49:52AM +0800, Qu Wenruo wrote:
Change subject to reflect the core of the conversation.
Zygo Blaxell wrote on 2015/07/21 18:14 -0400:
On Tue, Jul 21, 2015 at 02:52:38PM +0800, Qu Wenruo wrote:
Zygo Blaxell wrote on 201
28 matches
Mail list logo
