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

At 08/09/2016 10:24 AM, Goldwyn Rodrigues wrote: On 08/08/2016 08:12 PM, Qu Wenruo wrote: At 08/09/2016 09:01 AM, Goldwyn Rodrigues wrote: On 08/08/2016 07:26 PM, Qu Wenruo wrote: At 08/08/2016 10:54 AM, Goldwyn Rodrigues wrote: On 08/07/2016 07:39 PM, Qu Wenruo wrote: At

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

On 08/08/2016 08:12 PM, Qu Wenruo wrote: > > > At 08/09/2016 09:01 AM, Goldwyn Rodrigues wrote: >> >> >> On 08/08/2016 07:26 PM, Qu Wenruo wrote: >>> >>> >>> At 08/08/2016 10:54 AM, Goldwyn Rodrigues wrote: On 08/07/2016 07:39 PM, Qu Wenruo wrote: > > > At 08/07/2016

[PATCH] btrfs: waiting on qgroup rescan should not always be interruptible

From: Jeff Mahoney We wait on qgroup rescan completion in three places: file system shutdown, the quota disable ioctl, and the rescan wait ioctl. If the user sends a signal while we're waiting, we continue happily along. This is expected behavior for the rescan wait ioctl.

Re: [PATCH v12.2 01/15] btrfs: expand btrfs_set_extent_delalloc() and its friends to support in-band dedupe and subpage size patchset

Hi David and Chandan, I see the expansion of cow_file_range() function got merged into 4.8 window, while this patch is still not merged yet, is there anything wrong with this patch? Thanks, Qu At 07/19/2016 04:50 PM, Qu Wenruo wrote: Extract btrfs_set_extent_delalloc() and

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

At 08/09/2016 09:01 AM, Goldwyn Rodrigues wrote: On 08/08/2016 07:26 PM, Qu Wenruo wrote: At 08/08/2016 10:54 AM, Goldwyn Rodrigues wrote: On 08/07/2016 07:39 PM, Qu Wenruo wrote: At 08/07/2016 01:19 AM, Goldwyn Rodrigues wrote: Thanks Qu, This patch set fixes all the reported

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

On 08/08/2016 07:26 PM, Qu Wenruo wrote: > > > At 08/08/2016 10:54 AM, Goldwyn Rodrigues wrote: >> >> >> On 08/07/2016 07:39 PM, Qu Wenruo wrote: >>> >>> >>> At 08/07/2016 01:19 AM, Goldwyn Rodrigues wrote: Thanks Qu, This patch set fixes all the reported problems. However, I

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

At 08/08/2016 10:54 AM, Goldwyn Rodrigues wrote: On 08/07/2016 07:39 PM, Qu Wenruo wrote: At 08/07/2016 01:19 AM, Goldwyn Rodrigues wrote: Thanks Qu, This patch set fixes all the reported problems. However, I have some minor issues with coding style. Thanks for the test. On

Re: [lkp] [dm flakey] 99f3c90d0d: WARNING: CPU: 20 PID: 1027 at fs/btrfs/extent-tree.c:2973 btrfs_run_delayed_refs+0x2c5/0x2f0 [btrfs]

On 08/08/2016 02:27 PM, Linus Torvalds wrote: This report should probably have gone to the btrfs people, although it doesn't really look like a bug. It looks like it's just dm-flakey now returning more errors, and causing btrfs to complain more. Which seems entirely expected. Maybe the

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

Ivan Sizov posted on Mon, 08 Aug 2016 19:30:16 +0300 as excerpted: > I'd ran "rm -rf //" by mistake two days ago. I'd stopped it after five > seconds, but some files had been deleted. I'd tried to shutdown the > system, but couldn't (a lot of files in /bin had been deleted and > systemd didn't

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

2016-08-08 21:52 GMT+03:00 Hugo Mills : > On Mon, Aug 08, 2016 at 09:38:28PM +0300, Ivan Sizov wrote: >> P.S. IMHO, log replay by default is a quite dangerous thing. I didn't >> know about that change and I could lose all files if the live USB had >> 4.6 kernel)) > >Log

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

On Mon, Aug 08, 2016 at 09:38:28PM +0300, 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 they get

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

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 they get deleted on a rw mount. > > This is what kernel? Because kernel 4.6

Re: [lkp] [dm flakey] 99f3c90d0d: WARNING: CPU: 20 PID: 1027 at fs/btrfs/extent-tree.c:2973 btrfs_run_delayed_refs+0x2c5/0x2f0 [btrfs]

This report should probably have gone to the btrfs people, although it doesn't really look like a bug. It looks like it's just dm-flakey now returning more errors, and causing btrfs to complain more. Which seems entirely expected. Maybe the robot just was testing a error case that didn't

Re: [PATCH 17/17] xfs: test realtime rmapbt code

On Mon, Aug 08, 2016 at 05:08:00PM +0800, Eryu Guan wrote: > On Thu, Jul 21, 2016 at 04:48:07PM -0700, Darrick J. Wong wrote: > > Test the realtime rmap btree code by exercising various IO patterns > > on realtime files. > > > > Signed-off-by: Darrick J. Wong > > --- > >

Re: [PATCH 15/17] xfs: scrub fs (if still mounted) at the end of the test

On Mon, Aug 08, 2016 at 04:52:39PM +0800, Eryu Guan wrote: > On Thu, Jul 21, 2016 at 04:47:51PM -0700, Darrick J. Wong wrote: > > Teach _check_xfs_filesystem to scrub mounted filesystems before > > unmounting and fscking them. This is mostly to test the online > > scrub tool... > > > >

Re: [PATCH 14/17] xfs: more rmapbt tests

On Mon, Aug 08, 2016 at 04:48:14PM +0800, Eryu Guan wrote: > On Thu, Jul 21, 2016 at 04:47:45PM -0700, Darrick J. Wong wrote: > > More tests for the reverse mapping functionality. > > > > Signed-off-by: Darrick J. Wong > > --- > > tests/xfs/876 | 76

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

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. > > > > Signed-off-by: Darrick J. Wong > > --- > > tests/xfs/873 |

Re: [PATCH 12/17] reflink: test cross-mountpoint reflink and dedupe

On Mon, Aug 08, 2016 at 03:56:01PM +0800, Eryu Guan wrote: > On Thu, Jul 21, 2016 at 04:47:32PM -0700, Darrick J. Wong wrote: > > Test sharing blocks via reflink and dedupe between two different > > mountpoints of the same filesystem. This shouldn't work, since > > we don't allow cross-mountpoint

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

On Mon, Aug 8, 2016 at 10:30 AM, Ivan Sizov wrote: > I'd ran "rm -rf //" by mistake two days ago. I'd stopped it after five > seconds, but some files had been deleted. I'd tried to shutdown the > system, but couldn't (a lot of files in /bin had been deleted and > systemd

Strange behavior after "rm -rf //"

I'd ran "rm -rf //" by mistake two days ago. I'd stopped it after five seconds, but some files had been deleted. I'd tried to shutdown the system, but couldn't (a lot of files in /bin had been deleted and systemd didn't work). After hard reboot (by reset button) and booting to a live USB a strange

Re: Crash in btrfs_uuid_tree_iterate during mount

On 08/08/2016 10:21 AM, Nikolay Borisov wrote: On 08/08/2016 05:16 PM, Chris Mason wrote: Fantastic, thanks again for digging through it. Making the patch is much easier than testing the patch in this case. If you can trigger this semi-reliably, we can add some debugging to make sure we're

Re: Crash in btrfs_uuid_tree_iterate during mount

On 08/08/2016 05:16 PM, Chris Mason wrote: > > Fantastic, thanks again for digging through it. Making the patch is > much easier than testing the patch in this case. If you can trigger > this semi-reliably, we can add some debugging to make sure we're not > papering over some other problem.

Re: Crash in btrfs_uuid_tree_iterate during mount

On 08/08/2016 06:49 AM, Nikolay Borisov wrote: On 08/05/2016 06:12 PM, Chris Mason wrote: Hello Chris, Indeed it seems that btrfs_uuid_iter_rem returned a ENOENT: callq 0xa081f450 mov%eax,%r13d je 0xa081f882 ; if uuid_iter_rem

Re: Save way to migrate from raid 5/6?

Thank you Justin, I successfully converted two machines running raid5 to raid10 by doing `btrfs balance -dconvert=10 -mconvert=10 /mountpoint`. I performed a full backup before, I also calculated the shasum of all files on the arrays before and after the conversion and it seems I got away with no

Re: Save way to migrate from raid 5/6?

Do not run device delete, the issue is with parity and disk-failure recovery, manually incurring disk failure is a very bad idea. I would suggest running a full backup of all the files before touching anything and then an in place conversion should be fine as its just reading from undegraded

Re: Crash in btrfs_uuid_tree_iterate during mount

On 08/05/2016 06:12 PM, Chris Mason wrote: > > On 08/05/2016 07:08 AM, Nikolay Borisov wrote: >> Hello, >> >> Recently I started getting the following crashes on some servers, >> running btrfs: >> >> [340435.480338] BTRFS info (device loop7): disk space caching is enabled >> [340435.480509]

Re: [PATCH 17/17] xfs: test realtime rmapbt code

On Thu, Jul 21, 2016 at 04:48:07PM -0700, Darrick J. Wong wrote: > Test the realtime rmap btree code by exercising various IO patterns > on realtime files. > > Signed-off-by: Darrick J. Wong > --- > tests/xfs/878 | 88 +++ >

Re: [PATCH 15/17] xfs: scrub fs (if still mounted) at the end of the test

On Thu, Jul 21, 2016 at 04:47:51PM -0700, Darrick J. Wong wrote: > Teach _check_xfs_filesystem to scrub mounted filesystems before > unmounting and fscking them. This is mostly to test the online > scrub tool... > > Signed-off-by: Darrick J. Wong > --- > README

Re: [PATCH 14/17] xfs: more rmapbt tests

On Thu, Jul 21, 2016 at 04:47:45PM -0700, Darrick J. Wong wrote: > More tests for the reverse mapping functionality. > > Signed-off-by: Darrick J. Wong > --- > tests/xfs/876 | 76 +++ > tests/xfs/876.out |4 ++ >

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

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. > > Signed-off-by: Darrick J. Wong > --- > tests/xfs/873 | 107 > + >

Re: [PATCH 12/17] reflink: test cross-mountpoint reflink and dedupe

On Thu, Jul 21, 2016 at 04:47:32PM -0700, Darrick J. Wong wrote: > Test sharing blocks via reflink and dedupe between two different > mountpoints of the same filesystem. This shouldn't work, since > we don't allow cross-mountpoint functions. > > Signed-off-by: Darrick J. Wong

Re: memory overflow or undeflow in free space tree / space_info?

Am 04.08.2016 um 13:40 schrieb Stefan Priebe - Profihost AG: > Am 29.07.2016 um 23:03 schrieb Josef Bacik: >> On 07/29/2016 03:14 PM, Omar Sandoval wrote: >>> On Fri, Jul 29, 2016 at 12:11:53PM -0700, Omar Sandoval wrote: On Fri, Jul 29, 2016 at 08:40:26PM +0200, Stefan Priebe - Profihost