1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
Return-Path: <obnam-dev-bounces@obnam.org>
X-Original-To: distix@pieni.net
Delivered-To: distix@pieni.net
Received: from bagpuss.pepperfish.net (bagpuss.pepperfish.net [148.251.8.16])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by pieni.net (Postfix) with ESMTPS id AC4DE2062E
for <distix@pieni.net>; Sat, 1 Nov 2014 22:51:22 +0100 (CET)
Received: from platypus.pepperfish.net (unknown [10.112.100.20])
by bagpuss.pepperfish.net (Postfix) with ESMTP id 44281345B;
Sat, 1 Nov 2014 21:51:22 +0000 (GMT)
Received: from localhost ([::1] helo=platypus.pepperfish.net)
by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian))
id 1XkgZu-0005gG-55; Sat, 01 Nov 2014 21:51:22 +0000
Received: from inmail ([10.112.100.10] helo=mx0.pepperfish.net)
by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian))
id 1XkgZs-0005g9-Pm
for <obnam-dev@obnam.org>; Sat, 01 Nov 2014 21:51:20 +0000
Received: from smtp5-g21.free.fr ([212.27.42.5])
by mx0.pepperfish.net with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
(Exim 4.80) (envelope-from <tmp.obnam-dev@pcedev.com>)
id 1XkgZo-0003PE-Cr
for obnam-dev@obnam.org; Sat, 01 Nov 2014 21:51:20 +0000
Received: from [10.0.0.5] (unknown [62.147.215.125])
by smtp5-g21.free.fr (Postfix) with ESMTP id AB21ED48044
for <obnam-dev@obnam.org>; Sat, 1 Nov 2014 22:49:07 +0100 (CET)
Message-ID: <545555CF.4020405@pcedev.com>
Date: Sat, 01 Nov 2014 22:51:11 +0100
From: Olivier Jolly <tmp.obnam-dev@pcedev.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: obnam-dev@obnam.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.1
X-Spam-Score-int: -30
X-Spam-Bar: ---
X-Scanned-By: pepperfish.net, Sat, 01 Nov 2014 21:51:19 +0000
X-Spam-Report: Content analysis details: (-3.1 points)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.5 PPF_USER_AGENT User-Agent: exists
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust [212.27.42.5 listed in list.dnswl.org]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
Subject: R43272X "fix" proposal
X-BeenThere: obnam-dev@obnam.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Obnam development discussions <obnam-dev-obnam.org>
List-Unsubscribe: <http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-dev-obnam.org>,
<mailto:obnam-dev-request@obnam.org?subject=unsubscribe>
List-Archive: <http://listmaster.pepperfish.net/pipermail/obnam-dev-obnam.org>
List-Post: <mailto:obnam-dev@obnam.org>
List-Help: <mailto:obnam-dev-request@obnam.org?subject=help>
List-Subscribe: <http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-dev-obnam.org>,
<mailto:obnam-dev-request@obnam.org?subject=subscribe>
Sender: obnam-dev-bounces@obnam.org
Errors-To: obnam-dev-bounces@obnam.org
hi,
regarding the R43272X error about missing chunk which is being
discussed recently on the support mailing list, I've also been impacted
by it and spent a bit of time investigating it but would prefer to have
some feedback to know whether I should keep going in this direction or not.
My understanding is that this error indicate a missing file which
holds a chunk of data for one or more files (or part of one or more files).
Basically, it's an unrecoverable error.
However, as it is coded today, when this condition is met, this error
leads to a stop of the current sub command (like forget, probably
restore and mount).
In order to recover from it as good as possible, I wondered whether
the fsck sub command may dereference the file pointing to the missing
chunk. To do this, I looked at the fsck code and the chunk checking work
item can be given the file+genid related to the checked chunk to have
knowledge of the file referencing the missing data.
At this point, as far as I understood the repo interface doesn't have
a working method to remove a file from a past generation (there are
several comment about repo alteration methods only working on the last
generation).
Reading the Btree/larch documentation and code, I think that the
removal of the key for a file in a given generation (ie the given
generation Btree) should be working. So I tried to perform the
generation btree loading, perform the removal on the tree (pasting most
of the existing file 'remove' method) and then commiting the journal via
the commit method on the client metadata (where I'm unsure it would
propagate to the btree I've altered).
At this point, it didn't change anything and before diving into the
code again, I wanted to have some feedback regarding the overall
approach of dealing with R43272X (because it could be handled by making
this error not fatal and implying soft "empty/missing file" behaviour
hence leading to a fresh backup on the next backup attempt to mitigate
the data loss). And if the reference removal is agreed on, I wanted to
know if I was right in thinking that reference removal in the given
generation would be a potential fix (potentially with a file salvage
option to recover the valid chunks for the corrupted file).
Thanks in advance,
Olivier Jolly
_______________________________________________
obnam-dev mailing list
obnam-dev@obnam.org
http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-dev-obnam.org
|
