checksum error in metadata node - best way to move root fs to new drive?

btrfs scrub returned with uncorrectable errors. Searching in dmesg returns the following information: BTRFS warning (device dm-0): checksum error at logical N on /dev/mapper/[crypto] sector: y metadata node (level 2) in tree 250 it also says: unable to fixup (regular) error at logical

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

On Tue, Aug 9, 2016 at 6:29 PM, Matt McKinnon 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 else is going to have to

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

# btrfs check /dev/sda1 Checking filesystem on /dev/sda1 UUID: 33f9089e-acc7-4a39-8b83-b18bb182faaf checking extents ref mismatch on [958277767168 5894144] extent item 0, found 1 Backref 958277767168 root 257 owner 15799573 offset 750342144 num_refs 0 not found in extent tree Incorrect local

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

Spoke too soon. Do I need to continue to run with that mount option in place? [ 83.775984] BTRFS warning (device sda1): block group 25741009879040 has wrong amount of free space [ 83.775989] BTRFS warning (device sda1): failed to load free space cache for block group 25741009879040,

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

-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

btrfs check --repair error: check_owner_ref: Assertion `rec->is_root` failed.

New problems keep happening... Now btrfs check --repair is giving an error: check_owner_ref: Assertion `rec->is_root` failed. I do not know what that means, but I did run the command as root (as shown in the images of the screen) images of errors are here: http://imgur.com/a/ZwkUR SUMMARY of

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

On Tue, Aug 9, 2016 at 6:01 PM, Chris Murphy wrote: > On Tue, Aug 9, 2016 at 5:15 PM, Matt McKinnon wrote: >> Hello, >> >> Our server recently crashed and was rebooted. When it returned our BTRFS >> volume is mounting read-only: > > What happens

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

On Tue, Aug 9, 2016 at 5:15 PM, Matt McKinnon 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

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

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

Re: Strange behavior after "rm -rf //"

On Mon, 8 Aug 2016, Ivan Sizov wrote: > I'd ran "rm -rf //" by mistake two days ago. I'd stopped it after five Out of curiosity, what version of coreutils is this? The --preserve-root option is the default for quite some time now: > Don't include dirname.h, since system.h does it now. > (usage,

Re: system locked up with btrfs-transaction consuming 100% CPU

The original problem from 2 days ago just happened again. I ran btrfs rescue zero-log (again) and the root filesystem mounted but it was read-only on first boot. I rebooted again and everything seems normal. But clearly there is a problem that needs to be resolved. Problem: The root file system

Re: recent complete stalls of btrfs (4.7.0-rc2+) -- any advice?

"happy" to provide more information or enable any necessary additional monitoring to provide more information in case of the next crash. I have rebooted the box around 11am, and it was completely unresponsive since some time earlier but I think it still "somewhat functioned" afte

Re: system locked up with btrfs-transaction consuming 100% CPU

Thank you for the info, Duncan. I will use Alt-sysrq-s alt-sysrq-u alt-sysrq-b. This is the best description / recommendation I've read on the subject. I had read about these special key sequences before but I could never remember them and I didn't fully understand what they did. Now you have

Re: system locked up with btrfs-transaction consuming 100% CPU

Dave T posted on Tue, 09 Aug 2016 14:07:46 -0400 as excerpted: > I hard reset my system, expecting the worst, but it rebooted normally. > journalctl -xb -p3 showed no entries. I don't have any suggestions for your primary problem, tho I do have a comment down below, but I do have a suggestion

Re: [PATCH 1/2] remove mapping from balance_dirty_pages*()

Hi Josef, [auto build test WARNING on linus/master] [also build test WARNING on v4.8-rc1 next-20160809] [cannot apply to linux/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Josef-Bacik

Re: Strange behavior after "rm -rf //"

Chris Murphy posted on Tue, 09 Aug 2016 11:10:08 -0600 as excerpted: > On Mon, Aug 8, 2016 at 12:38 PM, Ivan Sizov wrote: >> 2016-08-08 20:13 GMT+03:00 Chris Murphy : >>> Just a wild guess, the deletions may be in the tree log and haven't >>> been

Re: [PATCH 1/2] remove mapping from balance_dirty_pages*()

Hi Josef, [auto build test ERROR on linus/master] [also build test ERROR on v4.8-rc1 next-20160809] [cannot apply to linux/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Josef-Bacik

Re: btrfs dev del hangs on 4.7

On Tue, Aug 09, 2016 at 03:22:03PM -0400, Chris Mason wrote: > > > On 08/09/2016 03:11 PM, Hugo Mills wrote: > >On Tue, Aug 09, 2016 at 06:27:33PM +, Hugo Mills wrote: > >>On Tue, Aug 09, 2016 at 02:26:14PM -0400, Chris Mason wrote: > >>>On 08/09/2016 02:23 PM, Hugo Mills wrote: > Hi,

Re: [PATCH 1/2] remove mapping from balance_dirty_pages*()

Hi Josef, [auto build test ERROR on linus/master] [also build test ERROR on v4.8-rc1 next-20160809] [cannot apply to linux/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Josef-Bacik

Re: [PATCH 1/2] remove mapping from balance_dirty_pages*()

Hi Josef, [auto build test WARNING on linus/master] [also build test WARNING on v4.8-rc1 next-20160809] [cannot apply to linux/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Josef-Bacik

Re: btrfs dev del hangs on 4.7

On 08/09/2016 03:11 PM, Hugo Mills wrote: On Tue, Aug 09, 2016 at 06:27:33PM +, Hugo Mills wrote: On Tue, Aug 09, 2016 at 02:26:14PM -0400, Chris Mason wrote: On 08/09/2016 02:23 PM, Hugo Mills wrote: Hi, Chris, On Tue, Aug 09, 2016 at 02:02:20PM -0400, Chris Mason wrote: On

Re: btrfs dev del hangs on 4.7

On Tue, Aug 09, 2016 at 06:27:33PM +, Hugo Mills wrote: > On Tue, Aug 09, 2016 at 02:26:14PM -0400, Chris Mason wrote: > > On 08/09/2016 02:23 PM, Hugo Mills wrote: > > > Hi, Chris, > > > > > >On Tue, Aug 09, 2016 at 02:02:20PM -0400, Chris Mason wrote: > > >>On 08/09/2016 01:27 PM, Hugo

[PATCH 0/2][RFC] Provide accounting for dirty metadata

Btrfs has always had a dummy inode that we used to allocate pages for our metadata. This has allowed us to take advantage of balance_dirty_pages() since our dirty metadata is unbounded otherwise. This has worked fine for years, but now we want to add sub pagesize blocksize support. The easiest

[PATCH 2/2] writeback: allow for dirty metadata accounting

Provide a mechanism for file systems to indicate how much dirty metadata they are holding. This introduces a few things 1) Zone stats for dirty metadata, which is the same as the NR_FILE_DIRTY. 2) WB stat for dirty metadata. This way we know if we need to try and call into the file system to

[PATCH 1/2] remove mapping from balance_dirty_pages*()

The only reason we pass in the mapping is to get the inode in order to see if writeback cgroups is enabled, and even then it only checks the bdi and a super block flag. balance_dirty_pages() doesn't even use the mapping. Since balance_dirty_pages*() works on a bdi level, just pass in the bdi and

Re: btrfs dev del hangs on 4.7

On Tue, Aug 09, 2016 at 02:26:14PM -0400, Chris Mason wrote: > On 08/09/2016 02:23 PM, Hugo Mills wrote: > > Hi, Chris, > > > >On Tue, Aug 09, 2016 at 02:02:20PM -0400, Chris Mason wrote: > >>On 08/09/2016 01:27 PM, Hugo Mills wrote: > >>> Over the weekend, I started doing some maintenance on

Re: btrfs dev del hangs on 4.7

On 08/09/2016 02:23 PM, Hugo Mills wrote: Hi, Chris, On Tue, Aug 09, 2016 at 02:02:20PM -0400, Chris Mason wrote: On 08/09/2016 01:27 PM, Hugo Mills wrote: Over the weekend, I started doing some maintenance on my server: I upgraded to 4.7.0, and I started deleting a device from my array,

Re: btrfs dev del hangs on 4.7

Hi, Chris, On Tue, Aug 09, 2016 at 02:02:20PM -0400, Chris Mason wrote: > On 08/09/2016 01:27 PM, Hugo Mills wrote: > > Over the weekend, I started doing some maintenance on my server: I > >upgraded to 4.7.0, and I started deleting a device from my array, > >preparatory to putting in a

system locked up with btrfs-transaction consuming 100% CPU

My system locked up with btrfs-transaction consuming 100% CPU and NMI watchdog reporting BUG: soft lockup with btrfs-transaction:314. This comes 2 days after a serious event involving BTRFS where my system would not mount the root fs. (I gave details in an email to the list two days ago and

Re: btrfs dev del hangs on 4.7

On 08/09/2016 01:27 PM, Hugo Mills wrote: Over the weekend, I started doing some maintenance on my server: I upgraded to 4.7.0, and I started deleting a device from my array, preparatory to putting in a larger one. About halfway through the operation, several kernel threads hung up for a

btrfs dev del hangs on 4.7

Over the weekend, I started doing some maintenance on my server: I upgraded to 4.7.0, and I started deleting a device from my array, preparatory to putting in a larger one. About halfway through the operation, several kernel threads hung up for a while (resulting in "blocked for 120s"

Re: Strange behavior after "rm -rf //"

On Mon, Aug 8, 2016 at 12:38 PM, Ivan Sizov wrote: > 2016-08-08 20:13 GMT+03:00 Chris Murphy : >> Just a wild guess, the deletions may be in the tree log and haven't >> been applied to the other trees (fs tree, extent tree, etc). So yes >> I'd expect

Re: Issue: errno:28 (No space left on device)

On Tue, Aug 9, 2016 at 3:06 AM, Thomas wrote: > thomas@pc8-nb:~$ uname -a > Linux pc8-nb 4.6.1-towo.1-siduction-amd64 #1 SMP PREEMPT siduction 4.6-1 > (2016-06-04) x86_64 GNU/Linux Try 4.5.7 or 4.7 and see if it fixes the problem, there's a related patch in both of those that's

Re: Issue: errno:28 (No space left on device)

On Tue, 9 Aug 2016 09:39:45 -0400 Noah Massey wrote: > Since your data and metadata profiles are both 'single', you may want > to consider creating the filesystem with the --mixed option, which > allows / forces BTRFS to use a single collection of data blocks for > both

Re: Issue: errno:28 (No space left on device)

On 08/09/2016 07:50 AM, Thomas wrote: Hello! I'm facing a severe issue with Debian installation using BTRFS: errno:28 (No space left on device) After a few minutes of system usage I get this error message for any action, means there's really no disk space left. However, the output of btrfs fi

Re: Issue: errno:28 (No space left on device)

On Tue, Aug 9, 2016 at 8:56 AM, Austin S. Hemmelgarn wrote: > On 2016-08-09 07:50, Thomas wrote: >> >> Hello! > > First things first: > Mailing lists are asynchronous. You will almost _never_ get an immediate > response, and will quite often not get a response for a few

Re: [PATCH v3 3/3] btrfs: qgroup: Fix qgroup incorrectness caused by log replay

On 08/09/2016 03:30 AM, Qu Wenruo wrote: > When doing log replay at mount time(after power loss), qgroup will leak > numbers of replayed data extents. > > The cause is almost the same of balance. > So fix it by manually informing qgroup for owner changed extents. > > The bug can be detected by

Re: [PATCH v3 2/3] btrfs: relocation: Fix leaking qgroups numbers on data extents

On 08/09/2016 03:30 AM, Qu Wenruo wrote: > When balancing data extents, qgroup will leak all its numbers for > relocated data extents. > > The relocation is done in the following steps for data extents: > 1) Create data reloc tree and inode > 2) Copy all data extents to data reloc tree >And

Re: [PATCH v3 1/3] btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent()

On 08/09/2016 03:30 AM, Qu Wenruo wrote: > Refactor btrfs_qgroup_insert_dirty_extent() function, to two functions: > 1. _btrfs_qgroup_insert_dirty_extent() >Almost the same with original code. >For delayed_ref usage, which has delayed refs locked. > >Change the return value type to

Re: "No space left on device" and balance doesn't work

On Tue, Aug 9, 2016 at 7:16 AM, Austin S. Hemmelgarn wrote: > On 2016-08-09 05:50, MegaBrutal wrote: >> >> 2016-06-03 14:43 GMT+02:00 Austin S. Hemmelgarn : >>> >>> >>> Also, since you're on a new enough kernel, try 'lazytime' in the mount >>> options

Re: Issue: errno:28 (No space left on device)

On 2016-08-09 07:50, Thomas wrote: Hello! First things first: Mailing lists are asynchronous. You will almost _never_ get an immediate response, and will quite often not get a response for a few hours at least. Sending a message more than once when you don't get a response does not make it

Re: Issue: errno:28 (No space left on device)

On Tue, Aug 09, 2016 at 01:50:04PM +0200, Thomas wrote: > Hello! > > I'm facing a severe issue with Debian installation using BTRFS: > errno:28 (No space left on device) Sending this message 3x won't make it more important. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's

Issue: errno:28 (No space left on device)

Hello! I'm facing a severe issue with Debian installation using BTRFS: errno:28 (No space left on device) After a few minutes of system usage I get this error message for any action, means there's really no disk space left. However, the output of btrfs fi usage / reports that ~10% of disk

Re: "No space left on device" and balance doesn't work

On 2016-08-09 05:50, MegaBrutal wrote: 2016-06-03 14:43 GMT+02:00 Austin S. Hemmelgarn : Also, since you're on a new enough kernel, try 'lazytime' in the mount options as well, this defers all on-disk timestamp updates for up to 24 hours or until the inode gets written

Re: "No space left on device" and balance doesn't work

2016-06-03 14:43 GMT+02:00 Austin S. Hemmelgarn : > > Also, since you're on a new enough kernel, try 'lazytime' in the mount > options as well, this defers all on-disk timestamp updates for up to 24 hours > or until the inode gets written out anyway, but keeps the updated

Issue: errno:28 (No space left on device)

Hello! I'm facing a severe issue with Debian installation using BTRFS: errno:28 (No space left on device) After a few minutes of system usage I get this error message for any action, means there's really no disk space left. However, the output of btrfs fi usage / reports that ~10% of disk

Issue: errno:28 (No space left on device)

Hello! I'm facing a severe issue with Debian installation using BTRFS: errno:28 (No space left on device) After a few minutes of system usage I get this error message for any action, means there's really no disk space left. However, the output of btrfs fi usage / reports that ~10% of disk

[PATCH v3 1/3] btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent()

Refactor btrfs_qgroup_insert_dirty_extent() function, to two functions: 1. _btrfs_qgroup_insert_dirty_extent() Almost the same with original code. For delayed_ref usage, which has delayed refs locked. Change the return value type to int, since caller never needs the pointer, but only

[PATCH v3 3/3] btrfs: qgroup: Fix qgroup incorrectness caused by log replay

When doing log replay at mount time(after power loss), qgroup will leak numbers of replayed data extents. The cause is almost the same of balance. So fix it by manually informing qgroup for owner changed extents. The bug can be detected by btrfs/119 test case. Cc: Mark Fasheh

[PATCH v2 0/3] Qgroup fix for dirty hack routines

This patchset introduce 2 fixes for data extent owner hacks. One can be triggered by balance, another one can be trigged by log replay after power loss. Root cause are all similar: EXTENT_DATA owner is changed by dirty hacks, from swapping tree blocks containing EXTENT_DATA to manually update

[PATCH v3 2/3] btrfs: relocation: Fix leaking qgroups numbers on data extents

When balancing data extents, qgroup will leak all its numbers for relocated data extents. The relocation is done in the following steps for data extents: 1) Create data reloc tree and inode 2) Copy all data extents to data reloc tree And commit transaction 3) Create tree reloc tree(special

Re: [PATCH 13/17] xfs: test swapext with reflink

On Mon, Aug 08, 2016 at 10:41:32AM -0700, Darrick J. Wong wrote: > On Mon, Aug 08, 2016 at 04:13:59PM +0800, Eryu Guan wrote: > > On Thu, Jul 21, 2016 at 04:47:38PM -0700, Darrick J. Wong wrote: > > > Add a few tests to stress the new swapext code for reflink and rmap. > > > +_reflink_range