Re: runtime btrfsck

2017-05-11 Thread Duncan
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

Re: runtime btrfsck

2017-05-10 Thread Stefan Priebe - Profihost AG
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 -

Re: runtime btrfsck

2017-05-10 Thread Hugo Mills
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 > >

Re: runtime btrfsck

2017-05-10 Thread Stefan Priebe - Profihost AG
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

Re: runtime btrfsck

2017-05-10 Thread Hugo Mills
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

Re: runtime btrfsck

2017-05-10 Thread Roman Mamedov
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

Re: runtime btrfsck

2017-05-10 Thread Stefan Priebe - Profihost AG
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

Re: runtime btrfsck

2017-05-10 Thread Stefan Priebe - Profihost AG
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

Re: runtime btrfsck

2017-05-10 Thread 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 unresolved. But I clearly saw that btrfs check was running in a

Re: runtime btrfsck

2017-05-10 Thread 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 key order: > block=163316514816,root=1, slot=39 >

Re: runtime btrfsck

2017-05-10 Thread Stefan Priebe - Profihost AG
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

Re: runtime btrfsck

2017-05-10 Thread Marat Khalili
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)

Re: runtime btrfsck

2017-05-10 Thread Roman Mamedov
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

Re: runtime btrfsck

2017-05-10 Thread Stefan Priebe - Profihost AG
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

Re: runtime btrfsck

2017-05-05 Thread Stefan Priebe - Profihost AG
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

runtime btrfsck

2017-05-02 Thread 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 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