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 abort
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 "-r
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
/ho
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
> t
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 it's
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
> ref
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 perfo
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
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 from this list: send
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:
> >>
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
--
To unsubscribe from this list: sen
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, it
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 te
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 until
%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 bd
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 -
fs/btrfs/disk-io.c | 1 -
fs/btrfs
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, it'
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 pointer derefere
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 functionality but inst
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
>containin
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 `num_stripes == 0` triggered,
> val
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 .. imo, balance wouldn't help
--
To unsu
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 https://raw.githubusercontent.com/kdave/btrfs-progs/master/bt
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 int
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, t
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 inste
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 ./btrf
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 ke
28 matches
Mail list logo