Re: Unrecoverable scrub errors

I can assure you that drive (it is HDD) is perfectly functional with 0 SMART errors or warnings and doesn't have any problems. dmesg is clean in that regard too, HDD itself can be excluded from potential causes. There were however some memory-related issues on my machine a few months ago, so

Re: 4.14 balance: kernel BUG at /home/kernel/COD/linux/fs/btrfs/ctree.c:1856!

On Sat, 18 Nov 2017 02:08:46 +0100 Hans van Kranenburg wrote: > It's using send + balance at the same time. There's something that makes > btrfs explode when you do that. > > It's not new in 4.14, I have seen it in 4.7 and 4.9 also, various > different explosions

Re: Btrfs progs pre-release 4.14-rc1

Am 17.11.2017 um 21:08 schrieb Nick Terrell: On Nov 17, 2017, at 8:48 AM, Uli Heller wrote: I tried to compile these on ubuntu-14.04 running 4.4.0-98-generic - I had to install libzstd-dev - I had to disable the zstd tests Do you think this ends up in a working

Re: btrfs check fails with: btrfs_alloc_chunk: BUG_ON `ret` triggered, value -28

> On 14 Nov 2017, at 11:45 am, Chris Murphy wrote: > > On Mon, Nov 13, 2017 at 8:08 PM, Ben Hooper wrote: > >> [28205.454029] Code: 79 ff ff ff 49 8b 7c 24 60 89 da 48 c7 c6 68 c7 be a0 >> 31 c0 e8 12 4e fe ff eb 9b 89 de 48 c7 c7 38 c7 be a0 31

Re: [PATCH] btrfs: clear space cache inode generation always

On 17.11.2017 21:50, Josef Bacik wrote: > From: Josef Bacik > > We discovered a box that had double allocations, and suspected the space > cache may be to blame. While auditing the write out path I noticed that > if we've already setup the space cache we will just carry on.

Re: 4.14 balance: kernel BUG at /home/kernel/COD/linux/fs/btrfs/ctree.c:1856!

On 11/18/2017 12:48 PM, Hans van Kranenburg wrote: > > So, who wants to help? > > 1. Find a test system that you can crash. > 2. Create a test filesystem with some data. > 3. Run with 4.14? (makes the most sense I think) > 4. Continuously feed the data to balance and send everything to /dev/null

Re: [PATCH 2/2] btrfs: introduce feature to ignore a btrfs device

On 18.11.2017 15:50, Anand Jain wrote: > > > On 11/16/2017 10:11 PM, Nikolay Borisov wrote: >> >> >> On 13.11.2017 07:44, Anand Jain wrote: >>> Support for a new command is being added here: >>>   btrfs dev ignore >>> Which shall undo the effects of the command >>>   btrfs dev scan >>> >>>

Re: [PATCH 2/2] btrfs: introduce feature to ignore a btrfs device

On 11/16/2017 10:11 PM, Nikolay Borisov wrote: On 13.11.2017 07:44, Anand Jain wrote: Support for a new command is being added here: btrfs dev ignore Which shall undo the effects of the command btrfs dev scan This cli/ioctl is needed as there is no way to continue to mount in

Re: [PATCH 1/2] btrfs: refactor btrfs_free_stale_device() to get device list delete

On 11/16/2017 09:59 PM, Nikolay Borisov wrote: On 13.11.2017 07:44, Anand Jain wrote: We need to delete a device from the dev_list, so refactor btrfs_free_stale_device() for delete_device_from_list(). Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 27

Re: [PATCH 2/2] btrfs: introduce feature to ignore a btrfs device

On 11/16/2017 10:03 PM, Nikolay Borisov wrote: On 13.11.2017 07:44, Anand Jain wrote: Support for a new command is being added here: btrfs dev ignore Which shall undo the effects of the command btrfs dev scan This cli/ioctl is needed as there is no way to continue to mount in

Re: [PATCH v2] btrfs: handle dynamically reappearing missing device

On 11/17/2017 01:36 PM, Anand Jain wrote: > If the device is not present at the time of (-o degrade) mount, > the mount context will create a dummy missing struct btrfs_device. > Later this device may reappear after the FS is mounted and > then device is included in the device list but it missed

[PATCH v2 2/2] btrfs: introduce feature to ignore a btrfs device

Support for a new command is being added here: btrfs dev ignore Which shall undo the effects of the command btrfs dev scan This cli/ioctl is needed as there is no way to continue to mount in degraded mode if the device is already scanned, which is required to recover from the split brain raid

[PATCH v2 1/2] btrfs: add function to device list delete

We need device delete from the dev_list so create a new function, instead of refactor of btrfs_free_stale_device() because, btrfs_free_stale_device() doesn't hold device_list_mutex which is actually needed here. Signed-off-by: Anand Jain --- v1: title of this patch

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

On Sat, Nov 18, 2017 at 08:16:32AM +0800, Qu Wenruo wrote: > > item 27 key (1919785864 DIR_ITEM 2591417872) itemoff 14637 itemsize > > 46 > > location key (1919805647 INODE_ITEM 0) type FILE > > transid 2231988 data_len 0 name_len 16 > >

Re: 4.14 balance: kernel BUG at /home/kernel/COD/linux/fs/btrfs/ctree.c:1856!

On 11/18/2017 12:48 PM, Hans van Kranenburg wrote: > > So, who wants to help? > > 1. Find a test system that you can crash. > 2. Create a test filesystem with some data. > 3. Run with 4.14? (makes the most sense I think) > 4. Continuously feed the data to balance and send everything to /dev/null

Re: Unrecoverable scrub errors

On Sat, Nov 18, 2017 at 1:15 AM, Nazar Mokrynskyi wrote: > I can assure you that drive (it is HDD) is perfectly functional with 0 SMART > errors or warnings and doesn't have any problems. dmesg is clean in that > regard too, HDD itself can be excluded from potential

Re: Unrecoverable scrub errors

On Sat, Nov 18, 2017 at 10:13 PM, Nazar Mokrynskyi wrote: > > That was eventually useful: > > * found some familiar file names (mangled eCryptfs file names from times when > I used it for home directory) and decided to search for it in old snapshots > of home directory

Re: Unrecoverable scrub errors

On Sat, Nov 18, 2017 at 8:45 PM, Nazar Mokrynskyi wrote: > 19.11.17 05:19, Chris Murphy пише: >> On Sat, Nov 18, 2017 at 1:15 AM, Nazar Mokrynskyi >> wrote: >>> I can assure you that drive (it is HDD) is perfectly functional with 0 >>> SMART errors

bug? fstrim only trims unallocated space, not unused in bg's

fstrim should trim free space, but it only trims unallocated. This is with kernel 4.14.0 and the entire 4.13 series. I'm pretty sure it behaved this way with 4.12 also. [root@f27h ~]# fstrim -v / /: 39 GiB (41841328128 bytes) trimmed [root@f27h ~]# btrfs fi us / Overall: Device size:

Re: Unrecoverable scrub errors

19.11.17 05:19, Chris Murphy пише: > On Sat, Nov 18, 2017 at 1:15 AM, Nazar Mokrynskyi > wrote: >> I can assure you that drive (it is HDD) is perfectly functional with 0 SMART >> errors or warnings and doesn't have any problems. dmesg is clean in that >> regard too, HDD

Re: Unrecoverable scrub errors

19.11.17 06:33, Chris Murphy пише: > On Sat, Nov 18, 2017 at 8:45 PM, Nazar Mokrynskyi > wrote: >> 19.11.17 05:19, Chris Murphy пише: >>> On Sat, Nov 18, 2017 at 1:15 AM, Nazar Mokrynskyi >>> wrote: I can assure you that drive (it is HDD) is

Re: Unrecoverable scrub errors

19.11.17 07:23, Chris Murphy пише: > On Sat, Nov 18, 2017 at 10:13 PM, Nazar Mokrynskyi > wrote: > >> That was eventually useful: >> >> * found some familiar file names (mangled eCryptfs file names from times >> when I used it for home directory) and decided to search for

Re: bug? fstrim only trims unallocated space, not unused in bg's

19.11.2017 09:17, Chris Murphy пишет: > fstrim should trim free space, but it only trims unallocated. This is > with kernel 4.14.0 and the entire 4.13 series. I'm pretty sure it > behaved this way with 4.12 also. > Well, I was told it should also trim free space ...