Am Mi., 17. März 2021 um 02:54 Uhr schrieb Dāvis Mosāns :
> > root@hikitty:~$ install/btrfs-progs-5.9/btrfs check --readonly /dev/sdi1
> > Opening filesystem to check...
> > checksum verify failed on 99593231630336 found 00B6 wanted
> > checksum verify failed on 124762809384960 found
Am Mi., 17. März 2021 um 03:59 Uhr schrieb Chris Murphy
:
>
> On Tue, Mar 16, 2021 at 7:39 PM Qu Wenruo wrote:
> > > Using that restore I was able to restore approx. 7 TB of the
> > > originally stored 22 TB under that directory.
> > > Unfortunately nearly all the files are damaged. Small text fil
On Tue, Mar 16, 2021 at 7:39 PM Qu Wenruo wrote:
> > Using that restore I was able to restore approx. 7 TB of the
> > originally stored 22 TB under that directory.
> > Unfortunately nearly all the files are damaged. Small text files are
> > still OK. But every larger binary file is useless.
> > Is
otrd., 2021. g. 23. febr., plkst. 17:51 — lietotājs Sebastian Roller
() rakstīja:
>
[...]
>
> root@hikitty:~$ install/btrfs-progs-5.9/btrfs check --readonly /dev/sdi1
> Opening filesystem to check...
> checksum verify failed on 99593231630336 found 00B6 wanted
> checksum verify failed
s against chunks: -5
[165101.895065] BTRFS error (device sdf1): open_ctree failed
Since I desperately need the data I ran btrfs restore.
root@hikitty:~$ install/btrfs-progs-5.9/btrfs -v restore -i -s -m -S
--path-regex '^/(|@(|/backup(|/home(|/.*$' /dev/sdf1
/mnt/dumpo/home/
checksum ve
found E4E3BDB6 wanted
> > > checksum verify failed on 124762809384960 found E4E3BDB6 wanted
> > > checksum verify failed on 124762809384960 found E4E3BDB6 wanted
> > > checksum verify failed on 124762809384960 found E4E3BDB6 wanted
&g
found E4E3BDB6 wanted
> > checksum verify failed on 124762809384960 found E4E3BDB6 wanted
> > checksum verify failed on 124762809384960 found E4E3BDB6 wanted
> > bytenr mismatch, want=124762809384960, have=0
> > open with broken chunk error
> &g
root tree,
even if they're organized as being in a directory or in some other
subvolume.
>So for the snapshots there is only one option to use
> with btrfs restore -r.
It can be done by its own root node address using -f or by subvolid
using -r. The latter needs to be looked up in a relia
he corruption, and older ones are pointing to a mix of valid and
> stale blocks and it just ends up in confusion.
>
> I think what you're after is 'btrfs restore -f'
>
>-f
>only restore files that are under specified subvolume root
> pointe
cent roots are just bad due
to the corruption, and older ones are pointing to a mix of valid and
stale blocks and it just ends up in confusion.
I think what you're after is 'btrfs restore -f'
-f
only restore files that are under specified subvolume root
pointed by
d state than the backup. We used bcache with a
write-back cache on a ssd which is now completely dead (does not get
recognized by any server anymore). To get the file system mounted I
ran xfs-repair. After that only 6% of the data was left and this is
nearly completel
ot damaged.
Correct. They aren't actually damaged.
However, there's maybe 5-15 MiB of critical metadata on Btrfs, and if
it gets corrupt, the keys to the maze are lost. And it becomes
difficult, sometimes impossible, to "bootstrap" the file system. There
are backup entry poi
achine came up being unable to mount
the device.
> I think if the snapshot b-tree is ok, and the chunk b-tree is ok, then
> it should be possible to recover the data correctly without needing
> any other tree. I'm not sure if that's how btrfs restore already
> works.
>
> Ker
hat snapshot should be
> > > intact.
> >
> > i.e. the strategy for this is btrfs restore -r option
> >
> > That only takes subvolid. You can get a subvolid listing with -l
> > option but this doesn't show the subvolume names yet (patch is
> > pending)
> >
> > I think you best chance is to start out trying to restore from a
> > recent snapshot. As long as the failed controller wasn't writing
> > totally spurious data in random locations, that snapshot should be
> > intact.
>
> i.e. the strategy for this is btrfs re
he strategy for this is btrfs restore -r option
That only takes subvolid. You can get a subvolid listing with -l
option but this doesn't show the subvolume names yet (patch is
pending)
https://github.com/kdave/btrfs-progs/issues/289
As an alternative to applying that and building yourself, yo
721250] BTRFS error (device sdf1): bad tree block start, want
> 126718415241216 have 0
> [165101.750951] BTRFS error (device sdf1): bad tree block start, want
> 126718415241216 have 0
> [165101.755753] BTRFS error (device sdf1): failed to verify dev
> extents against chunks: -5
>
65101.755753] BTRFS error (device sdf1): failed to verify dev
extents against chunks: -5
[165101.895065] BTRFS error (device sdf1): open_ctree failed
Since I desperately need the data I ran btrfs restore.
root@hikitty:~$ install/btrfs-progs-5.9/btrfs -v restore -i -s -m -S
--path-regex '^/(|@(|
On Wed, Jul 04, 2018 at 04:09:50PM +0800, Anand Jain wrote:
> On 06/21/2018 01:51 AM, David Sterba wrote:
> > Commit 542c5908abfe84f7b4c1 ("btrfs: replace uuid_mutex by
> > device_list_mutex in btrfs_open_devices") switched to device_list_mutex
> > as we need that for the device list traversal, but
On 06/21/2018 01:51 AM, David Sterba wrote:
Commit 542c5908abfe84f7b4c1 ("btrfs: replace uuid_mutex by
device_list_mutex in btrfs_open_devices") switched to device_list_mutex
as we need that for the device list traversal, but we also need
uuid_mutex to protect access to fs_devices::opened to b
Commit 542c5908abfe84f7b4c1 ("btrfs: replace uuid_mutex by
device_list_mutex in btrfs_open_devices") switched to device_list_mutex
as we need that for the device list traversal, but we also need
uuid_mutex to protect access to fs_devices::opened to be consistent with
other users of that item.
CC:
le and dmesg for csum error
detection and correction.
Thanks
On Sat, Feb 24, 2018 at 8:36 PM, Qu Wenruo wrote:
>
>
> On 2018年02月24日 19:13, Marián Mlčoch wrote:
>> Hello,
>> i requst IRC , but nobody helps.
>> My primary question is , how mark restored files with ignore
On 2018年02月24日 19:13, Marián Mlčoch wrote:
> Hello,
> i requst IRC , but nobody helps.
> My primary question is , how mark restored files with ignored errors.
>
> btrfs restore –iv /vol /restorage
>
> this command restores files like charm but no marker for ok and bad
&
Hello,
i requst IRC , but nobody helps.
My primary question is , how mark restored files with ignored errors.
btrfs restore –iv /vol /restorage
this command restores files like charm but no marker for ok and bad files
(bad crc , bad ...). WHY?
This file system isnt newbie , i mean this is
Jorge Bastos posted on Wed, 22 Nov 2017 19:18:59 + as excerpted:
> Hello,
>
> While doing btrfs checksum testing I purposely corrupted a file and got
> the expect I/O error when trying to copy it, I also tested btrfs restore
> to see if I could recover a known corrupt file and
at 7:43 AM, Qu Wenruo wrote:
>
>
> On 2017年11月23日 13:25, Chris Murphy wrote:
>> On Wed, Nov 22, 2017 at 12:18 PM, Jorge Bastos
>> wrote:
>>> Hello,
>>>
>>> While doing btrfs checksum testing I purposely corrupted a file and
>>> got the expec
On 2017年11月23日 13:25, Chris Murphy wrote:
> On Wed, Nov 22, 2017 at 12:18 PM, Jorge Bastos
> wrote:
>> Hello,
>>
>> While doing btrfs checksum testing I purposely corrupted a file and
>> got the expect I/O error when trying to copy it, I also tested btrfs
>>
On Wed, Nov 22, 2017 at 12:18 PM, Jorge Bastos wrote:
> Hello,
>
> While doing btrfs checksum testing I purposely corrupted a file and
> got the expect I/O error when trying to copy it, I also tested btrfs
> restore to see if I could recover a known corrupt file and it did copy
>
Hello,
While doing btrfs checksum testing I purposely corrupted a file and
got the expect I/O error when trying to copy it, I also tested btrfs
restore to see if I could recover a known corrupt file and it did copy
it but there was no checksum error or warning. I used btrfs restore -v
Is this
Hello,
While doing btrfs checksum testing I purposely corrupted a file and
got the expect I/O error when trying to copy it, I also tested btrfs
restore to see if I could recover a known corrupt file and it did copy
it and there was no checksum error or warning, is this expect behavior
or should
.
"btrfs replace" should be your first option, not "btrfs restore", unless
it's totally damaged and you want to salvage as much as possible.
OK, thank you.
I used 'sudo btrfs restore -v /dev/sde1 /mnt/Old4TB' and
received 'Error mkdiring /mnt/Old4TB/Jay
replace" should be your first option, not "btrfs restore", unless
it's totally damaged and you want to salvage as much as possible.
> I used 'sudo btrfs restore -v /dev/sde1 /mnt/Old4TB' and
> received 'Error mkdiring /mnt/Old4TB/Jayda TV:2'.
No ext
Hello,
I thought I should report something since there was little information
on this error. The situation is I have 2 external hard drives on
Xubuntu. One is not working and I need to move the data over to the
other. I used 'sudo btrfs restore -v /dev/sde1 /mnt/Old4TB' and
recei
l, I did a clear_space
mount and that made it work again. A scrub revealed 2 csum errors,
each in a VM imagefle (35GB and 16GB), so I thought I use btrfs
restore this time to fix the backup, prepare for next month, without
growing the fs with 51GB and also get hints on the root cause of the
csum errors.
y). Or
alternatively to the manpage, you can check the mount options listing on
the wiki.
> After spending some time with Google I found a possible solution for my
> problem by running:
>
> btrfs restore -v /dev/sda /mnt/Data
>
> Actually this operation fails silently (compu
Chris Murphy posted on Fri, 20 May 2016 15:53:07 -0600 as excerpted:
>>btrfs fi show Label: none uuid: 93000933-e46d-403b-80d7-60475855e3f3
>> Total devices 2 FS bytes used 2.56TiB
>> devid1 size 2.73TiB used 2.71TiB path /dev/sda
>> devid4 size 2.73TiB used 2.71Ti
>btrfs fi show
>Label: none uuid: 93000933-e46d-403b-80d7-60475855e3f3
> Total devices 2 FS bytes used 2.56TiB
> devid1 size 2.73TiB used 2.71TiB path /dev/sda
> devid4 size 2.73TiB used 2.71TiB path /dev/sdb
OK so why does it only list two devices? This is a three d
What versions for kernel and btrfs-progs?
Have you tried only '-o ro,recovery' ? What kernel messages do you get for this?
Failure to read chunk tree message is usually bad. If you have a
recent enough btrfs-progs, try 'btrfs check' on the volume without
--repair and post the results; recent woul
possible solution for my problem
by running:
btrfs restore -v /dev/sda /mnt/Data
Actually this operation fails silently (computer freezes). After examine the
kernel logs I have found out that the operations fails because of „NO SPACE
LEFT ON DEVICE“. Can anybody please give me a solution for this
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 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
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 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
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-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: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 transid 625039
>>> /dev/sdm
>>> [
Sorry about the almost duplicate mail, Thunderbird's 'Send' button
happens to be right below 'Undo' when you open the edit menu...
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
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 transid 625039 /dev/sdm
[ 20.84] BTRFS: device label FSgyroA devid 10 transid 625039 /dev/sdn
[ 21.00412
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 transid 625039 /dev/sdm
[ 20.84] BTRFS: device label FSgyroA devid 10 transid 625039 /dev/sdn
[ 21.00412
much clearer.
Yeah. It took me awhile, some help from the list, and actually going
thru the process for real, once, to understand that page as well. As I
said, once you get to the point of the automatic btrfs restore not
working and needing the advanced stuff, the process gets /far/ more
te
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 transid 625039 /dev/sdm
> [ 20.84] BTRFS: device label FSgyroA devid 10 transid 625039 /dev/sdn
> [ 21.004127] BTRFS: device label FSgyroA devid
nately only) 26 transactions, and
> luckily all at the same transaction/generation number, you're likely
> beyond what the recovery mount option can deal with (I believe upto three
> transactions, tho it might be a few more in newer kernels), and obviously
> from your results, beyond w
current as the
limited risk didn't really justify updating the backups at a higher
frequency, so some effort to get more current versions is justified.
(I've actually been in that situation a couple times with some of my
btrfs. Fortunately, in both cases I was able to btrfs restore and
sdb /PublicA
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
nor can I restore data from the storage pool
pyrogyro ~ # btrfs restore -D -i -v
On onsdag 24 februari 2016 kl. 12:51:37 CET David Sterba wrote:
> Is it supposed to match only full path or also substrings? The way
> it's implemented it can match just part of the path but I'm not sure
> if this is intended or not.
>
> Paths in path-from-file:
>
> /a/b/c/d
>
> In filesystem
On Mon, Feb 22, 2016 at 06:53:23PM +0100, Henrik Asp wrote:
> --path-regex' syntax does not map well to restoring specific files.
> this patch introduces --path-from-file which takes a file listing
> files to restore.
> that file is memory mapped, and for every leaf, memmem is used to
> check if fs
but as someone who appreciates
the usefulness of btrfs restore, I definitely like the idea! =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
To unsubscribe from this lis
--path-regex' syntax does not map well to restoring specific files.
this patch introduces --path-from-file which takes a file listing
files to restore.
that file is memory mapped, and for every leaf, memmem is used to
check if fs_file is in that list.
Signed-off-by: Henrik Asp
Tested-by: Henrik A
Original Message
Subject: [PATCH 12/18] btrfs restore: check progress of file restoration
From:
To:
Date: 2014年12月11日 04:51
From: Martin Wilck
extents should be ordered by file offset. Expect no overlaps,
and report holes.
Signed-off-by: Martin Wilck
---
cmds-restore.c
Original Message
Subject: [PATCH 09/18] btrfs restore: more graceful error handling in
copy_file
From:
To:
Date: 2014年12月11日 04:51
From: Martin Wilck
Setting size and attributes of a file makes sense even if some
errors have occured during revovery.
Also, do something
From: Martin Wilck
Almost everyone who cares about her data will run btrfs restore
with -v. The "offset is" messages displayed will irritate users
because they reveal only btrfs internals. Users will think that
"offset" refers to a file offset and suspect severe corruption.
From: Martin Wilck
The logic to ask after 1024 extents is broken. It unnecessarily
confuses users if big files are being restored, making them think
somthing is going wrong.
Change it to two cases: 1) no or little progress restoring,
2) writing beyond the file size.
Signed-off-by: Martin Wilck
From: Martin Wilck
print a '+' for every 64k restored. This gives people more confidence
in long-running restore processes.
Signed-off-by: Martin Wilck
---
cmds-restore.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/cmds-restore.c b/cmds-restore.c
index f1c63
From: Martin Wilck
extents should be ordered by file offset. Expect no overlaps,
and report holes.
Signed-off-by: Martin Wilck
---
cmds-restore.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/cmds-restore.c b/cmds-restore.c
index 004c82e..80081b8 100644
--- a/
From: Martin Wilck
Setting size and attributes of a file makes sense even if some
errors have occured during revovery.
Also, do something useful with the number of bytes written.
Signed-off-by: Martin Wilck
---
cmds-restore.c | 27 ++-
1 files changed, 14 insertions(
From: Martin Wilck
A mismatch between the file size stored in the inode and the
number of bytes restored may indicate a problem.
restore reads data in 4k chunks, so it's normal that files are
truncated. Only emit the warning in unusual cases.
Signed-off-by: Martin Wilck
---
cmds-restore.c |
From: Martin Wilck
Track the number of bytes read from extents and restored.
This is useful for detecting errors and corruptions.
Signed-off-by: Martin Wilck
---
cmds-restore.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/cmds-restore.c b/cmds-restor
From: Martin Wilck
current btrfs restore will discard file attributes. This patch
sets them regular files and directories, as found in the
meta data.
Signed-off-by: Martin Wilck
---
cmds-restore.c | 116 ---
1 files changed, 101 insertions
From: Martin Wilck
Don't print whole path for files, which will mangle output
for long path names. Rather distinguish between directories
and files.
Signed-off-by: Martin Wilck
---
cmds-restore.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmds-restore.c b/cmds-
Robert White posted on Mon, 27 Oct 2014 17:39:13 -0700 as excerpted:
> On 10/26/2014 12:59 AM, Christian Tschabuschnig wrote:
>>
>> Hello,
>>
>> currently I am trying to recover a btrfs filesystem which had a few
>> subvolumes. When running # btrfs restore -sx
On 10/26/2014 12:59 AM, Christian Tschabuschnig wrote:
Hello,
currently I am trying to recover a btrfs filesystem which had a few subvolumes.
When running
# btrfs restore -sx /dev/xxx .
one subvolume gets restored.
Important Aside: The one time I had to resort to btrfs restore I didn't
Hello,
currently I am trying to recover a btrfs filesystem which had a few subvolumes.
When running
# btrfs restore -sx /dev/xxx .
one subvolume gets restored.
Would the restore utility report any corruption within this subvolume? May I
assume that all data was recovered if there are no
August 2014, 17:52:16 schrieb Gui Hecheng:
> > > > > On Mon, 2014-08-18 at 11:25 +0200, Marc Dietrich wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I did a checkout of the latest btrfs progs to repair my damaged
&
014-08-18 at 11:25 +0200, Marc Dietrich wrote:
> > > > > Hi,
> > > > >
> > > > > I did a checkout of the latest btrfs progs to repair my damaged
> > > > > filesystem.
> > > > > Running btrfs restore gives me several failed to
On 8/20/14, 10:35 PM, Gui Hecheng wrote:
> A memory problem reported by valgrind as follows:
> === Syscall param pwrite64(buf) points to uninitialised byte(s)
> When running:
> # valgrind --leak-check=yes btrfs restore /dev/sda9 /mnt/backup
>
> Because the output b
s follows:
>>>>=== Syscall param pwrite64(buf) points to uninitialised byte(s)
>>>>
>>>> When running:
>>>># valgrind --leak-check=yes btrfs restore /dev/sda9 /mnt/backup
>>>>
>>>> Because the output buf size is
014-08-18 at 11:25 +0200, Marc Dietrich wrote:
> > > > > Hi,
> > > > >
> > > > > I did a checkout of the latest btrfs progs to repair my damaged
> > > > > filesystem.
> > > > > Running btrfs restore gives me several failed to infl
> >
> > > > I did a checkout of the latest btrfs progs to repair my damaged
> > > > filesystem.
> > > > Running btrfs restore gives me several failed to inflate: -6 and
> > > > crashes
> > > > with some memory corruption. I ran it
Marc MERLIN merlins.org> writes:
>
> On Thu, Aug 21, 2014 at 05:52:01AM +, Mihail Zaporozhets wrote:
> > # btrfs-zero-log /dev/sda1
> > warning devid 5 not found already
> > Check tree block failed, want=16845270495232, have=0
> > read block failed check_tree_block
>
nts to uninitialised byte(s)
> >>
> >> When running:
> >># valgrind --leak-check=yes btrfs restore /dev/sda9 /mnt/backup
> >>
> >> Because the output buf size is alloced with malloc, but the length of
> >> output data is shorter than the sizeof(buf), s
aged
> > > filesystem.
> > > Running btrfs restore gives me several failed to inflate: -6 and crashes
> > > with some memory corruption. I ran it again with valgrind and got:
> > >
> > > valgrind --log-file=x2 -v --leak-check=yes btrfs restore /d
I just created
https://btrfs.wiki.kernel.org/index.php/Btrfs-zero-log
and added the info about this failure of btrfs-zero-log as well as the
patch from Chris.
Whenever it's in a new version of btrfs-zero-log, I or someone else can
update that wiki page to tell people to just update to a newer ver
On Thu, Aug 21, 2014 at 05:52:01AM +, Mihail Zaporozhets wrote:
> # btrfs-zero-log /dev/sda1
> warning devid 5 not found already
> Check tree block failed, want=16845270495232, have=0
> read block failed check_tree_block
> Couldn't read tree root
You may be hitting the
On 8/21/14, 1:42 PM, Eric Sandeen wrote:
> On 8/20/14, 10:35 PM, Gui Hecheng wrote:
>> A memory problem reported by valgrind as follows:
>> === Syscall param pwrite64(buf) points to uninitialised byte(s)
>> When running:
>> # valgrind --leak-check=yes btrfs re
On 8/20/14, 10:35 PM, Gui Hecheng wrote:
> A memory problem reported by valgrind as follows:
> === Syscall param pwrite64(buf) points to uninitialised byte(s)
> When running:
> # valgrind --leak-check=yes btrfs restore /dev/sda9 /mnt/backup
>
> Because the output b
Am Donnerstag, 21. August 2014, 17:52:16 schrieb Gui Hecheng:
> On Mon, 2014-08-18 at 11:25 +0200, Marc Dietrich wrote:
> > Hi,
> >
> > I did a checkout of the latest btrfs progs to repair my damaged
> > filesystem.
> > Running btrfs restore gives me several
On Mon, 2014-08-18 at 11:25 +0200, Marc Dietrich wrote:
> Hi,
>
> I did a checkout of the latest btrfs progs to repair my damaged filesystem.
> Running btrfs restore gives me several failed to inflate: -6 and crashes with
> some memory corruption. I ran it again with v
running:
> > # valgrind --leak-check=yes btrfs restore /dev/sda9 /mnt/backup
> >
> > Because the output buf size is alloced with malloc, but the length of
> > output data is shorter than the sizeof(buf), so valgrind report
> > uninitialised byte(s).
> > We
Hi Gui,
Am Donnerstag, 21. August 2014, 11:35:36 schrieb Gui Hecheng:
> A memory problem reported by valgrind as follows:
> === Syscall param pwrite64(buf) points to uninitialised byte(s)
> When running:
> # valgrind --leak-check=yes btrfs restore /dev/sda9 /mnt/backup
ne
disk fail.
mount -t btrfs -o degreded,ro,recovery,nospace_cache ...
mount -t btrfs -o recovery,nospace_cache ...
btrfs-find-root, btrfs-zero-log ..
Finaly:
btrfs restore -t 10404875644928 -v -i /dev/sda1 /mnt/uh1/eric/ -
Success! but some directory is absent; 3.4 TB restored, but 4 (availabl
A memory problem reported by valgrind as follows:
=== Syscall param pwrite64(buf) points to uninitialised byte(s)
When running:
# valgrind --leak-check=yes btrfs restore /dev/sda9 /mnt/backup
Because the output buf size is alloced with malloc, but the length of
output data is
On Mon, 2014-08-18 at 11:25 +0200, Marc Dietrich wrote:
> Hi,
>
> I did a checkout of the latest btrfs progs to repair my damaged filesystem.
> Running btrfs restore gives me several failed to inflate: -6 and crashes with
> some memory corruption. I ran it again with v
The value of variable leaf in while loop don't have to be set
for every round. Just move it outside.
Signed-off-by: Gui Hecheng
---
cmds-restore.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cmds-restore.c b/cmds-restore.c
index a6f535c..f417e0b 100644
--- a/cmds-restor
Hi,
I did a checkout of the latest btrfs progs to repair my damaged filesystem.
Running btrfs restore gives me several failed to inflate: -6 and crashes with
some memory corruption. I ran it again with valgrind and got:
valgrind --log-file=x2 -v --leak-check=yes btrfs restore /dev/sda9 /mnt
l 28, 2014 at 3:35 PM, Karl-Philipp Richter
>> wrote:
>>> Hi together,
>>> In the current HEAD (3f11e516db629f7a662bfd6376231817b4e34cc9) of
>>> https://github.com/kdave/btrfs-progs.git (I assume this list is the
>>> right address because I got some hints
14 at 3:35 PM, Karl-Philipp Richter
> wrote:
>> Hi together,
>> In the current HEAD (3f11e516db629f7a662bfd6376231817b4e34cc9) of
>> https://github.com/kdave/btrfs-progs.git (I assume this list is the
>> right address because I got some hints to the project from here) th
On Mon, Jul 28, 2014 at 3:35 PM, Karl-Philipp Richter
wrote:
> Hi together,
> In the current HEAD (3f11e516db629f7a662bfd6376231817b4e34cc9) of
> https://github.com/kdave/btrfs-progs.git (I assume this list is the
> right address because I got some hints to the project from here)
Hi together,
In the current HEAD (3f11e516db629f7a662bfd6376231817b4e34cc9) of
https://github.com/kdave/btrfs-progs.git (I assume this list is the
right address because I got some hints to the project from here) the
btrfs restore subcommand asks often (up to 100 time during restauration
of 400 GB
1 - 100 of 120 matches
Mail list logo
