On 03.11.2018 at 02:05 Qu Wenruo wrote:
> On 2018/11/3 上午1:18, M. Klingmann wrote:
>> On 02.11.2018 at 15:45 Qu Wenruo wrote:
>>> On 2018/11/2 下午10:30, M. Klingmann wrote:
On 31.10.2018 at 01:03 Qu Wenruo wrote:
> My plan for such recovery is:
>
> 1) btrfs ins dump-super to make
On 2018/11/3 上午1:18, M. Klingmann wrote:
> On 02.11.2018 at 15:45 Qu Wenruo wrote:
>> On 2018/11/2 下午10:30, M. Klingmann wrote:
>>> On 31.10.2018 at 01:03 Qu Wenruo wrote:
My plan for such recovery is:
1) btrfs ins dump-super to make sure system chunk array is valid
2)
On 02.11.2018 at 15:45 Qu Wenruo wrote:
> On 2018/11/2 下午10:30, M. Klingmann wrote:
>> On 31.10.2018 at 01:03 Qu Wenruo wrote:
>>> My plan for such recovery is:
>>>
>>> 1) btrfs ins dump-super to make sure system chunk array is valid
>>> 2) btrfs-find-root to find any valid chunk tree blocks
>>>
On 2018/11/2 下午10:30, M. Klingmann wrote:
>
> On 31.10.2018 at 01:03 Qu Wenruo wrote:
>> My plan for such recovery is:
>>
>> 1) btrfs ins dump-super to make sure system chunk array is valid
>> 2) btrfs-find-root to find any valid chunk tree blocks
>> 3) pass that chunk tree bytenr to
On 31.10.2018 at 01:03 Qu Wenruo wrote:
> My plan for such recovery is:
>
> 1) btrfs ins dump-super to make sure system chunk array is valid
> 2) btrfs-find-root to find any valid chunk tree blocks
> 3) pass that chunk tree bytenr to btrfs-restore
>Unfortunately, btrfs-restore doesn't support
On 31.10.2018 at 05:56 Chris Murphy wrote:
> On Tue, Oct 30, 2018 at 4:11 PM, Mirko Klingmann wrote:
>> Hi all,
>>
>> my btrfs root file system on a SD card broke down and did not mount anymore.
> It might mount with -o ro,nologreplay
>
> Typically an SD card will break in a way that it can't
On Tue, Oct 30, 2018 at 4:11 PM, Mirko Klingmann wrote:
> Hi all,
>
> my btrfs root file system on a SD card broke down and did not mount anymore.
It might mount with -o ro,nologreplay
Typically an SD card will break in a way that it can't write, and
mount will just hang (with mmcblk errors).
On 2018/10/31 上午4:11, Mirko Klingmann wrote:
> Hi all,
>
> my btrfs root file system on a SD card broke down and did not mount anymore.
>
> In retrospective, I think it reached its endurance, so I know that there
> is nothing to repair. All I want to do is to salvage some configuration
> and
Hi all,
my btrfs root file system on a SD card broke down and did not mount anymore.
In retrospective, I think it reached its endurance, so I know that there
is nothing to repair. All I want to do is to salvage some configuration
and data files from the remains left in my ISO file copy. The SD
On 2017-12-12 11:24, Hugo Mills wrote:
On Tue, Dec 12, 2017 at 04:18:09PM +, Neal Becker wrote:
Is it possible to check while it is mounted?
Certainly not while mounted read-write. While mounted read-only --
I'm not certain. Possibly.
In theory, it is possible, but I think that the
On Tue, Dec 12, 2017 at 04:18:09PM +, Neal Becker wrote:
> Is it possible to check while it is mounted?
Certainly not while mounted read-write. While mounted read-only --
I'm not certain. Possibly.
Hugo.
> On Tue, Dec 12, 2017 at 9:52 AM Hugo Mills wrote:
>
> >
On Tue, Dec 12, 2017 at 09:02:56AM -0500, Neal Becker wrote:
> sudo ls -la ~/
> [sudo] password for nbecker:
> ls: cannot access '/home/nbecker/.bash_history': No such file or directory
> ls: cannot access '/home/nbecker/.bash_history': No such file or directory
> ls: cannot access
sudo ls -la ~/
[sudo] password for nbecker:
ls: cannot access '/home/nbecker/.bash_history': No such file or directory
ls: cannot access '/home/nbecker/.bash_history': No such file or directory
ls: cannot access '/home/nbecker/.bash_history': No such file or directory
ls: cannot access
Am 14.11.2017 um 18:45 schrieb Andrei Borzenkov:
> 14.11.2017 12:56, Stefan Priebe - Profihost AG пишет:
>> Hello,
>>
>> after a controller firmware bug / failure i've a broken btrfs.
>>
>> # parent transid verify failed on 181846016 wanted 143404 found 143399
&
14.11.2017 12:56, Stefan Priebe - Profihost AG пишет:
> Hello,
>
> after a controller firmware bug / failure i've a broken btrfs.
>
> # parent transid verify failed on 181846016 wanted 143404 found 143399
>
> running repair, fsck or zero-log always results in the same fail
Hello,
after a controller firmware bug / failure i've a broken btrfs.
# parent transid verify failed on 181846016 wanted 143404 found 143399
running repair, fsck or zero-log always results in the same failure message:
extent-tree.c:2725: alloc_reserved_tree_block: BUG_ON `ret` triggered,
value
OK, I see. Maybe there is even more damaged...
Now I finished my second backup of the important data and just
killed this damaged raid. I created a new one and now I am restoring
my data. Let's hope it will last longer this time :)
Regards,
Tobias
2015-02-15 4:30 GMT+01:00 Liu Bo
On Fri, Feb 13, 2015 at 10:54:22PM +0100, Tobias Holst wrote:
It's me again. I just found out why my system crashed during the back up.
I don't know what it means, but maybe it helps you?
The warning means somehow checksum becomes inconsistent with file extents, but
no clear clues about the
On Fri, Feb 13, 2015 at 12:22:16AM +0100, Tobias Holst wrote:
Hi
I don't remember the exact mkfs.btrfs options anymore but
ls /sys/fs/btrfs/[UUID]/features/
shows the following output:
big_metadata compress_lzo extended_iref mixed_backref raid56
Well... mkfs.btrfs can specify a '-m'
2015-02-13 9:06 GMT+01:00 Liu Bo bo.li@oracle.com:
On Fri, Feb 13, 2015 at 12:22:16AM +0100, Tobias Holst wrote:
Hi
I don't remember the exact mkfs.btrfs options anymore but
ls /sys/fs/btrfs/[UUID]/features/
shows the following output:
big_metadata compress_lzo extended_iref
It's me again. I just found out why my system crashed during the back up.
I don't know what it means, but maybe it helps you?
WARNING: CPU: 7 PID: 22878 at
/home/kernel/COD/linux/fs/btrfs/extent_io.c:5203
read_extent_buffer+0xe3/0x120 [btrfs]()
Modules linked in: raid0(E) ufs(E) qnx4(E)
Hi
I don't remember the exact mkfs.btrfs options anymore but
ls /sys/fs/btrfs/[UUID]/features/
shows the following output:
big_metadata compress_lzo extended_iref mixed_backref raid56
I also tested my device with a short
hdparm -tT /dev/dm5
and got
/dev/mapper/sdc_crypt:
Timing cached
Ed Tomlinson e...@aei.ca schrieb:
On Tuesday, February 10, 2015 2:17:43 AM EST, Kai Krakow wrote:
Tobias Holst to...@tobby.eu schrieb:
and btrfs scrub status /[device] gives me the following output:
scrub status for [UUID]
scrub started at Mon Feb 9 18:16:38 2015 and was aborted after 2008
Hmm, it looks like it is getting worse... Here are some parts of my
syslog, including two crashed btrfs-threads:
So I am still getting many of these:
BTRFS (device dm-5): parent transid verify failed on 25033166798848 wanted
108976 found 108958
BTRFS warning (device dm-5): page private not
2015-02-10 8:17 GMT+01:00 Kai Krakow hurikha...@gmail.com:
Tobias Holst to...@tobby.eu schrieb:
and btrfs scrub status /[device] gives me the following output:
scrub status for [UUID]
scrub started at Mon Feb 9 18:16:38 2015 and was aborted after 2008
seconds total bytes scrubbed: 113.04GiB
Tobias Holst posted on Mon, 09 Feb 2015 23:45:21 +0100 as excerpted:
So a short summary:
- btrfs raid6 on 3.19.0 with btrfs-progs 3.19-rc2
- does not mount at boot up, open_ctree failed (disk 3)
- mounts successfully after bootup
- randomly checksum verify failed (disk 5)
- balance and
Hi
I'm having some trouble with my six-drives btrfs raid6 (each drive
encrypted with LUKS). At first: Yes, I do have backups, but it may
take at least days, maybe weeks or even some month to restore
everything from the (offside) backups. So it is not essential to
recover the data, but would be
Hi, I probably should have used a better subject title. Also, I submitted this
without knowing if it would be helpful or not. If it can be used in a good way
Great! If not, then no problem. I appreciate you getting back with me, Marc.
Thanks. :)
On 03/30/2014 12:50 AM, Marc MERLIN wrote:
On
Hi, I hadn't noticed this post,
I think I know the reason this time : you have used USB you bad guy!
I think USB does not support flush / barrier , which is mandatory for
BTRFS to work correctly in case of power loss.
For most filesystems actually, but the damages suffered by COW
filesystems
Bob Marley posted on Mon, 31 Mar 2014 19:04:38 +0200 as excerpted:
Hi, I hadn't noticed this post,
I think I know the reason this time : you have used USB you bad guy!
I think USB does not support flush / barrier , which is mandatory for
BTRFS to work correctly in case of power loss.
For
On Thu, Mar 20, 2014 at 11:21:27PM -0400, sepero...@gmx.com wrote:
Hello all. I submit bugs to different foss projects regularly, but I
don't really have a bug report this time. I have a broken filesystem
to report. And I have no idea how to reproduce it.
I am including a link to the
Hello all. I submit bugs to different foss projects regularly, but I don't
really have a bug report this time. I have a broken filesystem to report. And I
have no idea how to reproduce it.
I am including a link to the filesystem itself, because it appears to be
unrepairable and unrestorable.
Thanks Wang,
This was the result:
root@ubuntu:/downloads/btrfs-progs# ./btrfs chunk-recover /dev/sdc2
no recoverable chunk
Recover the chunk tree successfully.
Still unable to mount.
On Sun, Jul 14, 2013 at 2:03 PM, Wang Shilong wangshilong1...@gmail.com wrote:
Hello,
You call pull from:
I need some help as may have lost some number of files on a btrfs raid
1 volume. I'm not quite sure what happend which, I know, only adds to
the problem.
On my computer #1 I had only a month or so ago installed Fedora 19
Beta and at the time of install chose BTRFS, raid 1. Recently one of
the
On Sun, Jul 14, 2013 at 01:43:41PM +, Dave Barnum wrote:
I need some help as may have lost some number of files on a btrfs raid
1 volume. I'm not quite sure what happend which, I know, only adds to
the problem.
On my computer #1 I had only a month or so ago installed Fedora 19
Beta and
Thanks for your reply. I have tried -o degraded and recover but I
keep getting the error messages above in dmesg such as: btrfs: failed
to read chunk root on sdc2
On Sun, Jul 14, 2013 at 1:49 PM, Hugo Mills h...@carfax.org.uk wrote:
On Sun, Jul 14, 2013 at 01:43:41PM +, Dave Barnum wrote:
Hello,
You call pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
Miao implement chunk tree recover function, you can try it with like.
btrfs chunk-recover /dev
Maybe this can help you.
Thanks,
Wang
I need some help as may have lost some number of
Hi,
I have problems with a btrfs filesystem, and am holding on to it for
some more days before reformat.
What I am interested about is two things:
1. Is there any way to restore more stuff from the filesystem then
already fetched (it would help to get the system up faster, but nothing
really of
Hi,
I have problems with a btrfs filesystem, and am holding on to it for
some more days before reformat.
What I am interested about is two things:
1. Is there any way to restore more stuff from the filesystem then
already fetched (it would help to get the system up faster, but nothing
really of
On 21.07.2011 23:13, Jan Schubert wrote:
On 07/18/2011 10:29 AM, Jan Schmidt wrote:
If you are on a 3.0 kernel, get the most current version of btrfs
tools from Hugo's integration-20110705 branch at
http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ and do a
scrub. -Jan
Thx Jan, I
On 07/22/2011 09:24 AM, Jan Schmidt wrote:
Scrub should be printing inode numbers to your system log while
detecting those errors. If you want to know the exact files corrupted,
you can grab my patch set with subject Btrfs scrub: print path to
corrupted files and trigger nodatasum fixup from
On 07/18/2011 10:29 AM, Jan Schmidt wrote:
If you are on a 3.0 kernel, get the most current version of btrfs
tools from Hugo's integration-20110705 branch at
http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ and do a
scrub. -Jan
Thx Jan, I did. This is the result:
scrub status for
On 17.07.2011 16:01, Jan Schubert wrote:
Jan Schubert jan.schubert at gmx.li writes:
Please find some data and log below. Is there any chance to fix this?
After playing around (incl. deleting the log) I get the strong feeling
it has something todo with compression=lzo. Dunno why it started
Jan Schubert jan.schubert at gmx.li writes:
Please find some data and log below. Is there any chance to fix this?
After playing around (incl. deleting the log) I get the strong feeling
it has something todo with compression=lzo. Dunno why it started suddenly
but I disabled compression and did
For some while now I can reproduce a kernel oops. The reading of the oops migt
point to btrfs so I also did a btrfsk which gives me this warning before
aborting:
warning, start mismatch 13636968448 13636997120
I also find several entries in my dmesg concerning missing or wrong csum.
Please
Hello Chris,
Chris Mason hat am Wed 17. Feb, 09:11 (-0500) geschrieben:
On Tue, Feb 16, 2010 at 11:15:44AM +0100, Jörg Sommer wrote:
I've an utterly broken btrfs that makes btrfsck and btrfs-debug-tree
(version 0.19) die with a core dump. Are you interested in this
filesystem? Unfortunely
On Tue, Feb 16, 2010 at 11:15:44AM +0100, Jörg Sommer wrote:
Hi,
I've an utterly broken btrfs that makes btrfsck and btrfs-debug-tree
(version 0.19) die with a core dump. Are you interested in this
filesystem? Unfortunely, it has a size of 1TB and contains the backups of
our customers
Hi,
I've an utterly broken btrfs that makes btrfsck and btrfs-debug-tree
(version 0.19) die with a core dump. Are you interested in this
filesystem? Unfortunely, it has a size of 1TB and contains the backups of
our customers. Hence, I can't publish it. How can we come together?
Core
48 matches
Mail list logo