Roman Mamedov posted on Wed, 10 May 2017 13:52:55 +0500 as excerpted:
> So even with a minor corruption (something wonky in just ONE block of a
> multi-terabyte FS) the answer is way too often "nuke the entire thing
> and restore from backups".
Just another case where my "keep it small enough to
Hello,
thanks. But is there any way to recover from this error? Like removing
the item or so? Data loss isn't a problem. Just reconstructing the whole
FS will take quite a long time.
Stefan
Am 10.05.2017 um 11:54 schrieb Hugo Mills:
> On Wed, May 10, 2017 at 11:20:58AM +0200, Stefan Priebe -
On Wed, May 10, 2017 at 11:20:58AM +0200, Stefan Priebe - Profihost AG wrote:
> Hello,
>
> here's the output:
> # for block in 163316514816 163322413056 163325722624; do echo $block;
> btrfs-debug-tree -b $block /dev/mapper/crypt_md0|sed -re 's/(\t| )name:
> .*/\1name: HIDDEN/'; done
>
>
Hello,
here's the output:
# for block in 163316514816 163322413056 163325722624; do echo $block;
btrfs-debug-tree -b $block /dev/mapper/crypt_md0|sed -re 's/(\t| )name:
.*/\1name: HIDDEN/'; done
163316514816
btrfs-progs v4.8.5
leaf 163316514816 items 188 free space 1387 generation 86739 owner
On Wed, May 10, 2017 at 10:40:31AM +0200, Stefan Priebe - Profihost AG wrote:
> Am 10.05.2017 um 09:40 schrieb Hugo Mills:
> > On Wed, May 10, 2017 at 09:36:30AM +0200, Stefan Priebe - Profihost AG
> > wrote:
> >> Hello Roman,
> >>
> >> the FS is mountable. It just goes readonly when trying to
On Wed, 10 May 2017 09:48:07 +0200
Martin Steigerwald wrote:
> Yet, when it comes to btrfs check? Its still quite rudimentary if you ask me.
>
Indeed it is. It may or may not be possible to build a perfect Fsck, but IMO
for the time being, what's most sorely missing, is
Hi,
Am 10.05.2017 um 09:48 schrieb Martin Steigerwald:
> Stefan Priebe - Profihost AG - 10.05.17, 09:02:
>> I'm now trying btrfs progs 4.10.2. Is anybody out there who can tell me
>> something about the expected runtime or how to fix bad key ordering?
>
> I had a similar issue which remained
Am 10.05.2017 um 09:40 schrieb Hugo Mills:
> On Wed, May 10, 2017 at 09:36:30AM +0200, Stefan Priebe - Profihost AG wrote:
>> Hello Roman,
>>
>> the FS is mountable. It just goes readonly when trying to write some data.
>>
>> The kernel msgs are:
>> BTRFS critical (device dm-2): corrupt leaf, bad
Stefan Priebe - Profihost AG - 10.05.17, 09:02:
> I'm now trying btrfs progs 4.10.2. Is anybody out there who can tell me
> something about the expected runtime or how to fix bad key ordering?
I had a similar issue which remained unresolved.
But I clearly saw that btrfs check was running in a
On Wed, May 10, 2017 at 09:36:30AM +0200, Stefan Priebe - Profihost AG wrote:
> Hello Roman,
>
> the FS is mountable. It just goes readonly when trying to write some data.
>
> The kernel msgs are:
> BTRFS critical (device dm-2): corrupt leaf, bad key order:
> block=163316514816,root=1, slot=39
>
Hello Roman,
the FS is mountable. It just goes readonly when trying to write some data.
The kernel msgs are:
BTRFS critical (device dm-2): corrupt leaf, bad key order:
block=163316514816,root=1, slot=39
BTRFS critical (device dm-2): corrupt leaf, bad key order:
block=163322413056,root=1, slot=74
Hello,
(Warning: I'm a user, not a developer here.)
In my experience (on kernel 4.4) it processed larger and slower devices
within a day, BUT according to some recent topics the runaway
fragmentation (meaning in this case large number of small extents
regardless of their relative location)
On Wed, 10 May 2017 09:02:46 +0200
Stefan Priebe - Profihost AG wrote:
> how to fix bad key ordering?
You should clarify does the FS in question mount (read-write? read-only?)
and what are the kernel messages if it does not.
--
With respect,
Roman
--
To unsubscribe from
I'm now trying btrfs progs 4.10.2. Is anybody out there who can tell me
something about the expected runtime or how to fix bad key ordering?
Greets,
Stefan
Am 06.05.2017 um 07:56 schrieb Stefan Priebe - Profihost AG:
> It's still running. Is this the normal behaviour? Is there any other way
> to
It's still running. Is this the normal behaviour? Is there any other way
to fix the bad key ordering?
Greets,
Stefan
Am 02.05.2017 um 08:29 schrieb Stefan Priebe - Profihost AG:
> Hello list,
>
> i wanted to check an fs cause it has bad key ordering.
>
> But btrfscheck is now running since 7
Hello list,
i wanted to check an fs cause it has bad key ordering.
But btrfscheck is now running since 7 days. Current output:
# btrfsck -p --repair /dev/mapper/crypt_md0
enabling repair mode
Checking filesystem on /dev/mapper/crypt_md0
UUID: 37b15dd8-b2e1-4585-98d0-cc0fa2a5a7c9
bad key ordering
16 matches
Mail list logo