Re: 4.13: No space left with plenty of free space (/home/kernel/COD/linux/fs/btrfs/extent-tree.c:6989 __btrfs_free_extent.isra.62+0xc2c/0xdb0)

On 2017-09-08 13:33, Tomasz Chmielewski wrote: Just got this one in dmesg with btrfs RAID-1 on top of Linux software RAID-5. Should say: with btrfs _single_ on top of Linux software RAID-5. Why does it say "No space left" if we have 9 TB free there? [233787.920933] BTRFS: Transaction

Re: send | receive: received snapshot is missing recent files

I'm referring to the link below. Using "btrfs subvolume snapshot -r" copies the Received UUID from the source into the new snapshot. The btrbk FAQ entry suggests otherwise. Has something changed? The only way I see to remove a Received UUID is to create a rw snapshot (above command without the

4.13: No space left with plenty of free space (/home/kernel/COD/linux/fs/btrfs/extent-tree.c:6989 __btrfs_free_extent.isra.62+0xc2c/0xdb0)

Just got this one in dmesg with btrfs RAID-1 on top of Linux software RAID-5. Why does it say "No space left" if we have 9 TB free there? [233787.920933] BTRFS: Transaction aborted (error -28) [233787.920953] [ cut here ] [233787.920971] WARNING: CPU: 1 PID: 2235 at

Re: Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]

Marco Lorenzo Crociani posted on Thu, 07 Sep 2017 16:37:08 +0200 as excerpted: > This e-mail (including any attachments) is private and confidential, > and may be privileged. It is for the exclusive use of the intended > recipient(s). If you have received this email in error, please inform >

Re: [PATCH 00/10] Unused parameter cleanup

On Mon, Aug 21, 2017 at 12:43:40PM +0300, Nikolay Borisov wrote: > Here is a series that I've been sitting on for a while. It removes unused > parameter in various functions, no functional changes. Patch 09/10 reworks > some error handling to eliminate an if branch in __btrfs_alloc_chunk, but

Re: [PATCH 10/10] btrfs: Remove redundant argument of __link_block_group

On Mon, Aug 21, 2017 at 12:43:50PM +0300, Nikolay Borisov wrote: > __link_block_group is called from only 2 places and at each call site the > space_info being passed is the same as the space info assigned to the passed > cache struct. Let's remove the redundant argument and make the function >

Re: [PATCH 09/10] btrfs: Rework error handling of add_extent_mapping in __btrfs_alloc_chunk

On Mon, Aug 21, 2017 at 12:43:49PM +0300, Nikolay Borisov wrote: > Currently the code executes add_extent_mapping and if it is successful it > links > the new mapping, it then proceeds to unlock the extent mapping tree and check > for failure and handle them. Instead, rework the code to only

Re: [PATCH 07/10] btrfs: Remove unused parameter from extent_clear_unlock_delalloc

On Mon, Aug 21, 2017 at 12:43:47PM +0300, Nikolay Borisov wrote: > This variable was added as part of ba8b04c1d4ad ("btrfs: extend > btrfs_set_extent_delalloc and its friends to support in-band dedupe and > subpage size patchset") > however those patchsets haven't materialized yet. > Let's remove

Re: [PATCH 06/10] btrfs: Remove unused parameter from check_direct_IO

On Mon, Aug 21, 2017 at 12:43:46PM +0300, Nikolay Borisov wrote: > Introduced by 5a5f79b57069 ("Btrfs: allow unaligned DIO") and never used, The unaligned DIO -> buffered works as expected, so this parameter is indeend redundant. Reviewed-by: David Sterba -- To unsubscribe

Re: [PATCH 2/4] btrfs: convert enum btrfs_compression_type to define

On Wed, Aug 30, 2017 at 10:38:21PM +0800, Anand Jain wrote: > On 08/17/2017 07:57 PM, David Sterba wrote: > > On Thu, Aug 17, 2017 at 04:33:41AM +0800, Anand Jain wrote: > >> > >> > >> On 08/16/2017 09:59 PM, David Sterba wrote: > >>> On Sun, Aug 13, 2017 at 12:02:42PM +0800, Anand Jain wrote: >

Re: [PATCH v2] Btrfs: search parity device wisely

On Thu, Aug 03, 2017 at 01:53:31PM -0600, Liu Bo wrote: > After mapping block with BTRFS_MAP_WRITE, parities have been sorted to > the end position, so this search can start from the first parity > stripe. > > Signed-off-by: Liu Bo Reviewed-by: David Sterba

Re: [PATCH 1/2] btrfs: clear ordered flag on cleaning up ordered extents

On Fri, Sep 01, 2017 at 06:59:49PM +0800, Qu Wenruo wrote: > On 2017年09月01日 16:58, Naohiro Aota wrote: > > commit 524272607e88 ("btrfs: Handle delalloc error correctly to avoid > > ordered extent hang") introduced btrfs_cleanup_ordered_extents() to cleanup > > submitted ordered extents. However,

[PATCH 3/3] Btrfs: remove nr_async_submits and async_submit_draining

Now that we have the combo of flushing twice, which can make sure IO have started since the second flush will wait for page lock which won't be unlocked unless setting page writeback and queuing ordered extents, we don't need %async_submit_draining, %async_delalloc_pages and %nr_async_submits to

[PATCH 2/3] Btrfs: do not make defrag wait on async_delalloc_pages

By setting compression for a defrag task, the task will start IO at the end of defrag. After the combo of filemap_flush(), we've already made sure that dirty pages have made progress via async compress thread because the second filemap_flush() will wait for page lock, which won't be unlocked

[PATCH 0/3] kill async counters

%async_delalloc_pages and %nr_async_submits are used to indicate that compressed writeback actually starts its work, but since we have already used double filemap_flush() alike, we don't need those two any more. %nr_async_bios was used to show congestion for writeback, but a later change adopts

[PATCH 1/3] Btrfs: remove nr_async_bios

This was intended to congest higher layers to not send bios, but as 1) the congested bit has been taken by writeback 2) and no one is waiting for %nr_async_bios down to zero, we can safely remove this now. Signed-off-by: Liu Bo --- fs/btrfs/ctree.h | 1 -

Re: [PATCH 2/2] btrfs: finish ordered extent cleaning if no progress is found

On Fri, Sep 01, 2017 at 07:31:58PM +0800, Qu Wenruo wrote: > > > On 2017年09月01日 16:59, Naohiro Aota wrote: > > __endio_write_update_ordered() repeats the search until it reaches the end > > of the specified range. This works well with direct IO path, because before > > the function is called,

Re: [PATCH 5/7] Btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO

On Wed, Sep 06, 2017 at 05:37:28PM +0200, David Sterba wrote: > On Tue, Aug 22, 2017 at 11:46:03PM -0700, Omar Sandoval wrote: > > From: Omar Sandoval > > > > A naked read of the value of an RCU pointer isn't safe. Put the whole > > access in an RCU critical section, not just the

Re: [PATCH 3/7] Move Btrfs RCU string to common library

On Wed, Sep 06, 2017 at 05:15:06PM +0200, David Sterba wrote: > On Tue, Aug 22, 2017 at 11:46:01PM -0700, Omar Sandoval wrote: > > From: Omar Sandoval > > > > The RCU-friendly string API used internally by Btrfs is generic enough > > for common use. This doesn't add any new

Re: [PATCH v2] btrfs-progs: test: add new test for inspect-internal rootid

On Thu, Sep 07, 2017 at 10:48:27AM +0900, Misono, Tomohiro wrote: > This new test checks inspect-internal rootid > - handle path to subvolume/directory/file as an argument > - get different id for each subvolume > - get the expected id for each file/directory (i.e. the same as >

Re: [PATCH v2] btrfs-progs: print: Check on num_stripes in print_chunk

On Thu, Sep 07, 2017 at 10:28:25AM +0800, Su Yue wrote: > From: Zhang Yu > > In fuzz-tests/004-simple-dump-tree: > Since there is one wrong item(DATA_RELOC_TREE CHUNK_ITEM 0) in root > tree. > It fails as follow: > > ctree.h:317: btrfs_chunk_item_size: BUG_ON

Re: Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]

2017-09-07 16:37 GMT+02:00 Marco Lorenzo Crociani : [...] > I got: > > 00-49: 1 > 50-79: 0 > 80-89: 0 > 90-99: 1 > 100:25540 > > this means that fs has only one block group used under 50% and 1 between 90 > and 99% while the rest are all full? > yes ..

Re: Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]

Hi Peter, On 07/09/2017 14:04, Peter Becker wrote: You can check the usage of each block group with the following scripts. If there are many blockgroups with low usage you should run btrfs balance -musage= -dusage= /data cd /tmp wget

Re: send | receive: received snapshot is missing recent files

Having a received_uuid set on the source volume ("/home" in your case) is indeed a bad thing when it comes to send/receive. You probably restored a backup with send/receive, and made it read/write using "btrfs property set -ts /home ro false". This is a an evil thing, as it leaves received_uuid

Re: send | receive: received snapshot is missing recent files

I just ran a test. The btrfs send - receive problem I described is indeed fully resolved by removing the "problematic" snapshot on the target device. I did not make any changes to the source volume. I did not make any other changes in my steps (see earlier message for my exact steps). Therefore,

Re: send | receive: received snapshot is missing recent files

Hello. Can anyone further explain this issue ("you have a Received UUID on the source volume")? How does it happen? How does one remove a Received UUID from the source volume? And how does that explain my results where I showed that the problem is not dependent upon the source volume but is

Re: Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]

You can check the usage of each block group with the following scripts. If there are many blockgroups with low usage you should run btrfs balance -musage= -dusage= /data cd /tmp wget https://raw.githubusercontent.com/kdave/btrfs-progs/master/btrfs-debugfs chmod +x btrfs-debugfs stats=$(sudo

Re: Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]

On 05/09/2017 18:27, Liu Bo wrote: On Tue, Sep 05, 2017 at 11:47:26AM +0200, Marco Lorenzo Crociani wrote: Hi, I was transferring some data with rsync to a btrfs filesystem when I got: set 04 14:59:05 kernel: INFO: task kworker/u33:2:25015 blocked for more than 120 seconds. set 04 14:59:05

Re: send | receive: received snapshot is missing recent files

The problem can be that you have a Received UUID on the source volume. This breaks send-receive. From: Dave -- Sent: 2017-09-07 - 06:43 > Here is more info and a possible (shocking) explanation. This > aggregates my prior messages and it provides an almost