when looking through log for old messages I can see that there are
kernel problems before with extent tree while trying to create
snapshots:
Jan 23 05:00:02 server kernel: #011#011tree block backref root 7
Jan 23 05:00:02 server kernel: #011item 108 key (12288467451904 169 0)
itemoff 12677
Anyone ?
On 18 Feb 2017, at 16:44, Tomasz Kusmierz wrote:
So Qu,
currently my situation is that:
I've tried to go btrfs scan --repair, and it did relair some stuff is
qgroup's ... then tried to mont it and, surprise surpeire system
locked out in 20 seconds.
Reboot,
So Qu,
currently my situation is that:
I've tried to go btrfs scan --repair, and it did relair some stuff is
qgroup's ... then tried to mont it and, surprise surpeire system
locked out in 20 seconds.
Reboot, again scan --repair = a lot of missing back pointers were
repaired and system is
Thanks Qu,
Just before I’ll go and accidentally mess up this FS more - I’ve
mentioned originally that this problem started with FS not being able
to create a snapshot ( it would get remounted RO automatically ) for
about a month, and when I’ve realised that there is a problem like
that I’ve
At 02/15/2017 10:11 PM, Tomasz Kusmierz wrote:
So guys, any help here ? I’m kinda stuck now with system just idling and doing
nothing while I wait for some feedback ...
Sorry for the late reply.
Busying debugging a kernel bug.
On 14 Feb 2017, at 19:38, Tomasz Kusmierz
So guys, any help here ? I’m kinda stuck now with system just idling and doing
nothing while I wait for some feedback ...
> On 14 Feb 2017, at 19:38, Tomasz Kusmierz wrote:
>
> [root@server ~]# btrfs-show-super -af /dev/sdc
> superblock: bytenr=65536, device=/dev/sdc
>
[root@server ~]# btrfs-show-super -af /dev/sdc
superblock: bytenr=65536, device=/dev/sdc
-
csum_type 0 (crc32c)
csum_size 4
csum0x17d56ce0 [match]
bytenr 65536
flags
At 02/14/2017 08:23 AM, Tomasz Kusmierz wrote:
Forgot to mention:
btrfs inspect-internal dump-super -af /dev/sdc
Your btrfs-progs is somewhat old, which doesn't integrate dump super
into inspect-internal.
In that case, you can use btrfs-show-super -af instead.
Thanks,
Qu
btrfs
Forgot to mention:
btrfs inspect-internal dump-super -af /dev/sdc
btrfs inspect-internal: unknown token 'dump-super'
usage: btrfs inspect-internal
btrfs inspect-internal inode-resolve [-v]
Get file system paths for the given inode
btrfs inspect-internal logical-resolve [-Pv]
Problem is to send a larger log into this mailing list :/
Anyway: uname -a
Linux tevva-server 4.8.7-1.el7.elrepo.x86_64 #1 SMP Thu Nov 10
20:47:24 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
cut from messages (bear in mind that this is a single cut with a bit
cut from inside of it to fit it in the
At 02/12/2017 09:17 AM, Tomasz Kusmierz wrote:
Hi all,
So my main storage filesystem got some sort of veird corruption (that
I can gather). Everything seems to work OK, but when I try to create a
snapshot or run balance (no filters) it will get remounted read only.
Kernel version please.
Hi all,
So my main storage filesystem got some sort of veird corruption (that
I can gather). Everything seems to work OK, but when I try to create a
snapshot or run balance (no filters) it will get remounted read only.
Fun part is that balance seems to be running even on read only FS, and
I
12 matches
Mail list logo