No comment so blindly trying:
btrfsck --repair /dev/sdc
gave the following abort:
btrfsck: extent-tree.c:2736: alloc_reserved_tree_block: Assertion
`!(ret)' failed.
Full output attached.
All on:
3.11.2-gentoo
Btrfs v0.20-rc1-358-g194aa4a
For a 2TB single HDD formatted with defaults.
What
So...
The hint there is btrfsck: extent-tree.c:2736, so trying:
btrfsck --repair --init-extent-tree /dev/sdc
That ran for a while until:
kernel: btrfsck[16610]: segfault at cc ip 0041d2a7 sp
7fffd2c2d710 error 4 in btrfsck[40+4d000]
There's no other messages in the syslog.
What best to try next?
mount -o recovery,noatime
btrfsck:
--repairtry to repair the filesystem
--init-csum-treecreate a new CRC tree
--init-extent-tree create a new extent tree
or is a scrub worthwhile?
The fail and switch to read-only
So... The fix:
(
Summary:
Mounting -o recovery,noatime worked well and allowed a diff check to
complete for all but one directory tree. So very nearly all the data is
fine.
Deleting the failed directory tree caused a call stack dump and eventually:
kernel: parent transid verify failed on
On Oct 2, 2013, at 6:49 PM, Martin m_bt...@ml1.co.uk wrote:
kernel: btrfs read error corrected: ino 1 off 907183792128 (dev /dev/sdc
sector 1781821200)
Can anyone answer if this is what corrupt metadata detection and correction
looks like? From the original email this is a single disk, with
Martin posted on Sun, 29 Sep 2013 22:55:43 +0100 as excerpted:
On 29/09/13 22:29, Martin wrote:
Looking up what's available for Gentoo, the maintainers there look to
be nicely sharp with multiple versions available all the way up to
kernel 3.11.2...
Cool, another gentooer! =:^)
That is
On 29/09/13 06:11, Duncan wrote:
Martin posted on Sun, 29 Sep 2013 03:10:37 +0100 as excerpted:
So...
Any options for btrfsck to fix things?
Or is anything/everything that is fixable automatically fixed on the
next mount?
Or should:
btrfs scrub /dev/sdX
be run first?
Or?
What
On 29/09/13 22:29, Martin wrote:
Looking up what's available for Gentoo, the maintainers there look to be
nicely sharp with multiple versions available all the way up to kernel
3.11.2...
That is being pulled in now as expected:
sys-kernel/gentoo-sources-3.11.2
There's also the latest
On 28/09/13 23:54, Martin wrote:
On 28/09/13 20:26, Martin wrote:
... btrfsck bombs out with LOTs of errors...
How best to recover from this?
(This is a 'backup' disk so not 'critical' but it would be nice to avoid
rewriting about 1.5TB of data over the network...)
Is there an obvious
Martin posted on Sun, 29 Sep 2013 03:10:37 +0100 as excerpted:
So...
Any options for btrfsck to fix things?
Or is anything/everything that is fixable automatically fixed on the
next mount?
Or should:
btrfs scrub /dev/sdX
be run first?
Or?
What does btrfs do (or can do)
10 matches
Mail list logo
