Re: btrfs - kernel warning

Qu Wenruo posted on Fri, 02 Feb 2018 09:40:30 +0800 as excerpted: > > On 2018年02月02日 05:06, Patrik Ostrihon wrote: >> Hi, >> >> Today I saw warning in dmesg output. But I don't know what it means. >> Could you help me please? Is it something dangerous for my dato on this >> filesystem? >> >>

Re: btrfs - kernel warning

On Thu, Feb 1, 2018 at 6:40 PM, Qu Wenruo wrote: > Fortunately btrfs-progs provides offline tool to fix it. > You could use "btrfs rescue fix-device-size " to easily fix it. > And since it's an offline tool, you need to umount your fs first. > This feature first appears

Re: Writeback errors in kernel log with Linux 4.15 (m=s=raid1, d=raid5, 5 disks)

On Thu, Feb 1, 2018 at 6:37 PM, Janos Toth F. wrote: > Hmm... Actually, I just discovered a different machine with s=m=d=dup > (single HDD) spit out a few similar messages (a lot less and it took > longer for them to appear at all but it handles very little load): > > [

Re: Writeback errors in kernel log with Linux 4.15 (m=s=raid1, d=raid5, 5 disks)

On Thu, Feb 1, 2018 at 6:28 PM, Janos Toth F. wrote: > I started seeing these on my d=raid5 filesystem after upgrading to Linux 4.15. > > Some files created since the upgrade seem to be corrupted. How are you determining they're corrupt? Btrfs will spit back an I/O error

Re: btrfs - kernel warning

On 2018年02月02日 05:06, Patrik Ostrihon wrote: > Hi, > > Today I saw warning in dmesg output. But I don't know what it means. > Could you help me please? Is it something dangerous for my dato on > this filesystem? > > Thanks > > pa3k > > root@merkur:~# uname -a > > Linux merkur

Re: Writeback errors in kernel log with Linux 4.15 (m=s=raid1, d=raid5, 5 disks)

Hmm... Actually, I just discovered a different machine with s=m=d=dup (single HDD) spit out a few similar messages (a lot less and it took longer for them to appear at all but it handles very little load): [ 333.197366] WARNING: CPU: 0 PID: 134 at fs/fs-writeback.c:2339 __writeback_in

Re: [PATCH v2 0/3] btrfs-progs: Split lowmem mode check to its own

On 2018年02月02日 00:05, David Sterba wrote: > On Thu, Feb 01, 2018 at 02:45:38PM +0800, Qu Wenruo wrote: >> As usual, the main part is over 500K so the biggest patch won't reach >> mail list. >> Please fetch the whole branch from github: >>

Writeback errors in kernel log with Linux 4.15 (m=s=raid1, d=raid5, 5 disks)

I started seeing these on my d=raid5 filesystem after upgrading to Linux 4.15. Some files created since the upgrade seem to be corrupted. The disks seem to be fine (according to btrfs device stats and smartmontools device logs). The rest of the Btrfs filesystems (with m=s=d=single profiles) do

Re: btrfs - kernel warning

Oh and to be super clear, do not use --repair with 'btrfs check' until there's a dev recommendation to try it. It should be safe, but is still sometimes fragile in the multiple device case. --- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of

Re: btrfs - kernel warning

On Thu, Feb 1, 2018 at 2:06 PM, Patrik Ostrihon wrote: > Hi, > > Today I saw warning in dmesg output. But I don't know what it means. > Could you help me please? Is it something dangerous for my dato on > this filesystem? Is this a persistent warning you're getting or

btrfs - kernel warning

Hi, Today I saw warning in dmesg output. But I don't know what it means. Could you help me please? Is it something dangerous for my dato on this filesystem? Thanks pa3k root@merkur:~# uname -a Linux merkur 4.14.8-041408-generic #201712200555 SMP Wed Dec 20 10:57:38 UTC 2017 x86_64 x86_64

Re: [PATCH 04/26] libbtrfsutil: add btrfs_util_is_subvolume() and btrfs_util_subvolume_id()

On Tue, Jan 30, 2018 at 08:54:08AM +0200, Nikolay Borisov wrote: > > > On 29.01.2018 23:43, Omar Sandoval wrote: > > On Mon, Jan 29, 2018 at 12:24:26PM +0200, Nikolay Borisov wrote: > >> On 26.01.2018 20:40, Omar Sandoval wrote: > > [snip] > >>> +/* > >>> + * This intentionally duplicates

Re: [PATCH v2 0/3] btrfs-progs: Split lowmem mode check to its own

On Thu, Feb 01, 2018 at 02:45:38PM +0800, Qu Wenruo wrote: > As usual, the main part is over 500K so the biggest patch won't reach > mail list. > Please fetch the whole branch from github: > https://github.com/adam900710/btrfs-progs/tree/split_check Thanks, patches added to devel, with some more

Re: [PATCH v2 3/3] btrfs-progs: check: Cleanup all checkpatch error and warning

On Thu, Feb 01, 2018 at 10:28:13AM +0200, Nikolay Borisov wrote: > >>> @@ -3175,7 +3184,8 @@ static int check_extent_data_backref(struct > >>> btrfs_fs_info *fs_info, > >>>   btrfs_header_owner(leaf) != root_id) > >>>   goto next; > >>>   btrfs_item_key_to_cpu(leaf,

Re: [4.15-rc9] fs_reclaim lockdep trace

Peter Zijlstra wrote: > On Mon, Jan 29, 2018 at 08:47:20PM +0900, Tetsuo Handa wrote: > > Peter Zijlstra wrote: > > > On Sun, Jan 28, 2018 at 02:55:28PM +0900, Tetsuo Handa wrote: > > > > This warning seems to be caused by commit d92a8cfcb37ecd13 > > > > ("locking/lockdep: Rework FS_RECLAIM

Re: [PATCH v2 3/3] btrfs-progs: check: Cleanup all checkpatch error and warning

On 2018年02月01日 16:36, Nikolay Borisov wrote: > > > On 1.02.2018 08:45, Qu Wenruo wrote: >> Since we're moving tons of codes, it's a good idea to fix all errors and >> warnings from checkpatch. >> >> Signed-off-by: Qu Wenruo > > Having this patch separate for review is fine,

Re: [PATCH v2 3/3] btrfs-progs: check: Cleanup all checkpatch error and warning

On 1.02.2018 08:45, Qu Wenruo wrote: > Since we're moving tons of codes, it's a good idea to fix all errors and > warnings from checkpatch. > > Signed-off-by: Qu Wenruo Having this patch separate for review is fine, but in the end I think it will be best if it's squashed in

Re: [PATCH v2 3/3] btrfs-progs: check: Cleanup all checkpatch error and warning

On 1.02.2018 09:48, Qu Wenruo wrote: > > > On 2018年02月01日 15:08, Su Yue wrote: >> >> >> On 02/01/2018 02:45 PM, Qu Wenruo wrote: >>> Since we're moving tons of codes, it's a good idea to fix all errors and > [snip] >>>   } >>> @@ -2500,7 +2507,8 @@ static int

Re: [PATCH 2/2] btrfs: add read_mirror_policy parameter devid

On 02/01/2018 01:26 PM, Edmund Nadolski wrote: On 1/31/18 7:36 AM, Anand Jain wrote: On 01/31/2018 09:42 PM, Nikolay Borisov wrote: So usually this should be functionality handled by the raid/san controller I guess, > but given that btrfs is playing the role of a controller here at what