BUG during send, cannot delete subvolume

2018-04-12 Thread Matt McKinnon
Hi All, I had a ctree.c error during a send/receive backup: kernel BUG at fs/btrfs/ctree.c:1862 Nothing seemed to go wrong otherwise on the file system. After restarting the send, it completed, but I'm left with a subvolume I can't delete: BTRFS warning (device sdb1): Attempt to delete

Re: btrfs-transacti hammering the system

2017-12-01 Thread Matt McKinnon
on Fri, 01 Dec 2017 18:06:23 +0100 as excerpted: On 12/01/2017 05:31 PM, Matt McKinnon wrote: Sorry, I missed your in-line reply: 2) How big is this filesystem? What does your `btrfs fi df /mountpoint` say? # btrfs fi df /export/ Data, single: total=30.45TiB, used=30.25TiB System, DUP: total

Re: btrfs-transacti hammering the system

2017-12-01 Thread Matt McKinnon
, Hans van Kranenburg wrote: On 12/01/2017 06:57 PM, Holger Hoffstätte wrote: On 12/01/17 18:34, Matt McKinnon wrote: Thanks, I'll give space_cache=v2 a shot. Yes, very much recommended. My mount options are: rw,relatime,space_cache,autodefrag,subvolid=5,subvol=/ Turn autodefrag off and use

Re: btrfs-transacti hammering the system

2017-12-01 Thread Matt McKinnon
Thanks, I'll give space_cache=v2 a shot. My mount options are: rw,relatime,space_cache,autodefrag,subvolid=5,subvol=/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: btrfs-transacti hammering the system

2017-12-01 Thread Matt McKinnon
Sorry, I missed your in-line reply: 1) The one right above, btrfs_write_out_cache, is the write-out of the free space cache v1. Do you see this for multiple seconds going on, and does it match the time when it's writing X MB/s to disk? It seems to only last until the next watch update. []

Re: btrfs-transacti hammering the system

2017-12-01 Thread Matt McKinnon
These seem to come up most often: [] transaction_kthread+0x133/0x1c0 [btrfs] [] kthread+0x109/0x140 [] ret_from_fork+0x25/0x30 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: btrfs-transacti hammering the system

2017-12-01 Thread Matt McKinnon
Thanks for this. Here's what I get: [] transaction_kthread+0x133/0x1c0 [btrfs] [] kthread+0x109/0x140 [] ret_from_fork+0x25/0x30 ... [] io_schedule+0x16/0x40 [] get_request+0x23e/0x720 [] blk_queue_bio+0xc1/0x3a0 [] generic_make_request+0xf8/0x2a0 [] submit_bio+0x75/0x150 []

btrfs-transacti hammering the system

2017-12-01 Thread Matt McKinnon
Hi All, Is there any way to figure out what exactly btrfs-transacti is chugging on? I have a few file systems that seem to get wedged for days on end with this process pegged around 100%. I've stopped all snapshots, made sure no quotas were enabled, turned on autodefrag in the mount

kernel BUG at fs/btrfs/ctree.c:3182

2017-10-16 Thread Matt McKinnon
Hi All, Been having issues on one machine and I was wondering if I could get some help tracking the issue down. # uname -a Linux riperton 4.13.5-custom #1 SMP Sat Oct 7 18:28:16 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux # btrfs --version btrfs-progs v4.13.3 # btrfs fi show Label: none

Re: Struggling with file system slowness

2017-05-09 Thread Matt McKinnon
far the btrfs-transaction and memory spikes have not returned. -Matt On 05/09/2017 03:14 PM, Liu Bo wrote: On Fri, May 05, 2017 at 09:24:32AM -0400, Matt McKinnon wrote: Too little information. Is IO happening at the same time? Is compression on? Deduplicated? Lots of subvolumes? SSD? What

Struggling with file system slowness

2017-05-04 Thread Matt McKinnon
Hi All, Trying to peg down why I have one server that has btrfs-transacti pegged at 100% CPU for most of the time. I thought this might have to do with fragmentation as mentioned in the Gotchas page in the wiki (btrfs-endio-wri doesn't seem to be involved as mentioned in the wiki), but

Hard crash on 4.9.5, part 2

2017-01-30 Thread Matt McKinnon
I have an error on this file system I've had in the distant pass where the mount would fail with a "file exists" error. Running a btrfs check gives the following over and over again: Found file extent holes: start: 0, len: 290816 root 257 inode 28472371 errors 1000, some csum missing

Re: Hard crash on 4.9.5

2017-01-28 Thread Matt McKinnon
expected csum 0 Jan 27 19:42:47 my_machine kernel: [ 335.033249] BTRFS warning (device sda1): csum failed ino 28472371 off 8077312 csum 4031878292 expected csum 0 Can these be ignored? On 01/25/2017 04:06 PM, Liu Bo wrote: On Mon, Jan 23, 2017 at 03:03:55PM -0500, Matt McKinnon wrote: Wondering

Hard crash on 4.9.5

2017-01-23 Thread Matt McKinnon
Wondering what to do about this error which says 'reboot needed'. Has happened a three times in the past week: Jan 23 14:16:17 my_machine kernel: [ 2568.595648] BTRFS error (device sda1): err add delayed dir index item(index: 23810) into the deletion tree of the delayed node(root id: 257,

kernel crash after upgrading to 4.9

2017-01-04 Thread Matt McKinnon
Hi All, I seem to have a similar issue to a subject in December: Subject: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another In my case, this is caused when rsync'ing large amounts of data over NFS to the server with the BTRFS file system. This was not

Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2016-08-10 Thread Matt McKinnon
Chris Murphy wrote: On Tue, Aug 9, 2016 at 6:29 PM, Matt McKinnon <m...@techsquare.com> wrote: Spoke too soon. Do I need to continue to run with that mount option in place? It shouldn't be necessary. Something's still wrong for some reason, even with DUP metadata being CoW'd so someone e

Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2016-08-10 Thread Matt McKinnon
...@freenet.de wrote: Hi, from what i see you have a non finished balance ongoing, since you have system and metadata DUP and single information on disk. so you should (re)run a balance for this data. sash Am 10.08.2016 um 02:17 schrieb Matt McKinnon: -o usebackuproot worked well. after

Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2016-08-09 Thread Matt McKinnon
.6(__libc_start_main+0xf5)[0x7faad34cdf45] btrfs[0x40a0f9] and we crashed out of the check there. -Matt On 08/09/2016 08:06 PM, Chris Murphy wrote: On Tue, Aug 9, 2016 at 6:01 PM, Chris Murphy <li...@colorremedies.com> wrote: On Tue, Aug 9, 2016 at 5:15 PM, Matt McKinnon <m...@techs

Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2016-08-09 Thread Matt McKinnon
On Tue, Aug 9, 2016 at 5:15 PM, Matt McKinnon <m...@techsquare.com> wrote: Hello, Our server recently crashed and was rebooted. When it returned our BTRFS volume is mounting read-only: What happens when you try mounting with -o usebackuproot ? If that fails, what output do you get for

Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2016-08-09 Thread Matt McKinnon
-o usebackuproot worked well. after the file system settled, performing a sync and a clean umount, a normal mount works now as well. Anything I should be doing going forward? Thanks, Matt On 08/09/2016 08:01 PM, Chris Murphy wrote: On Tue, Aug 9, 2016 at 5:15 PM, Matt McKinnon &l

BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2016-08-09 Thread Matt McKinnon
Hello, Our server recently crashed and was rebooted. When it returned our BTRFS volume is mounting read-only: [ 142.395093] BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists [ 142.404418] BTRFS info (device sda1): forced readonly I tried

corruption, bad block, input/output errors - do i run --repair?

2014-11-07 Thread Matt McKinnon
Hi All, I'm running into some corruption and I wanted to seek out advice on whether or not to run btrfs check --repair, or if I should fall back to my backup file server, or both. The system is mountable, and usable. # uname -a Linux cbmm-fs 3.17.2-custom #1 SMP Thu Oct 30 14:09:57 EDT 2014