OK, an update: After unmouting and running btrfs check, the drive
reverted to reporting the old size. Not sure if this was due to
unmounting / mounting or doing btrfs check. Btrfs check should have
been running in readonly mode. Since it looked like something was
wrong with the resize process, I
On 2018/10/22 下午2:29, Otto Kekäläinen wrote:
> I never got a reply to this thread,
I replied to you but got no rely:
https://lore.kernel.org/linux-btrfs/eba5de6f-535a-0f5d-e415-9cd622d71...@gmx.com/
And your steps are just what I suggested.
Thanks,
Qu
> but I am not replying to myself in
>
I never got a reply to this thread, but I am not replying to myself in
case somebody has the same issue and is reading the archive:
The problem went away after:
- deleted all snapshots as they seemed to slow down btrfs I/O so much
that simple commands like rm and rsync were unusable
- replaced
On Mon, Oct 22, 2018 at 10:06 AM Andrew Nelson
wrote:
>
> OK, an update: After unmouting and running btrfs check, the drive
> reverted to reporting the old size. Not sure if this was due to
> unmounting / mounting or doing btrfs check. Btrfs check should have
> been running in readonly mode.
It
From: Filipe Manana
When we are writing out a free space cache, during the transaction commit
phase, we can end up in a deadlock which results in a stack trace like the
following:
schedule+0x28/0x80
btrfs_tree_read_lock+0x8e/0x120 [btrfs]
? finish_wait+0x80/0x80
From: Filipe Manana
We were iterating a block group's free space cache rbtree without locking
first the lock that protects it (the free_space_ctl->free_space_offset
rbtree is protected by the free_space_ctl->tree_lock spinlock).
KASAN reported an use-after-free problem when iterating such a
On Mon, Oct 22, 2018 at 10:10 AM wrote:
>
> From: Filipe Manana
>
> When we are writing out a free space cache, during the transaction commit
> phase, we can end up in a deadlock which results in a stack trace like the
> following:
>
> schedule+0x28/0x80
> btrfs_tree_read_lock+0x8e/0x120
On Mon, Oct 22, 2018 at 10:10 AM wrote:
>
> From: Filipe Manana
>
> When we are writing out a free space cache, during the transaction commit
> phase, we can end up in a deadlock which results in a stack trace like the
> following:
>
> schedule+0x28/0x80
> btrfs_tree_read_lock+0x8e/0x120
On Mon, Oct 22, 2018 at 08:10:37PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When we are writing out a free space cache, during the transaction commit
> phase, we can end up in a deadlock which results in a stack trace like the
> following:
>
> schedule+0x28/0x80
>
From: Filipe Manana
When we are writing out a free space cache, during the transaction commit
phase, we can end up in a deadlock which results in a stack trace like the
following:
schedule+0x28/0x80
btrfs_tree_read_lock+0x8e/0x120 [btrfs]
? finish_wait+0x80/0x80
On Mon, Oct 22, 2018 at 7:56 PM Josef Bacik wrote:
>
> On Mon, Oct 22, 2018 at 07:48:30PM +0100, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > When we are writing out a free space cache, during the transaction commit
> > phase, we can end up in a deadlock which results in a stack
Hi,
I think I lost power on my btrfs disk and it looks like it is now in an
unfunctional state.
Any idea how I could debug that issue?
Here is what I have:
kernel 4.4.0-119-generic
btrfs-progs v4.4
sudo btrfs check /dev/sdd
Checking filesystem on /dev/sdd
UUID:
On Mon, Oct 22, 2018 at 10:43:06AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> We were iterating a block group's free space cache rbtree without locking
> first the lock that protects it (the free_space_ctl->free_space_offset
> rbtree is protected by the free_space_ctl->tree_lock
From: Filipe Manana
When we are writing out a free space cache, during the transaction commit
phase, we can end up in a deadlock which results in a stack trace like the
following:
schedule+0x28/0x80
btrfs_tree_read_lock+0x8e/0x120 [btrfs]
? finish_wait+0x80/0x80
On Fri, Oct 19, 2018 at 05:43:18PM +0200, David Sterba wrote:
> On Thu, Sep 27, 2018 at 11:17:32AM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval
> > This series implements swap file support for Btrfs.
> >
> > Changes from v8 [1]:
> >
> > - Fixed a bug in btrfs_swap_activate() which would
On Mon, Oct 22, 2018 at 8:18 PM Josef Bacik wrote:
>
> On Mon, Oct 22, 2018 at 08:10:37PM +0100, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > When we are writing out a free space cache, during the transaction commit
> > phase, we can end up in a deadlock which results in a stack
On Mon, Oct 22, 2018 at 10:43:06AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
...
> Reported-by: Nikolay Borisov
> Signed-off-by: Filipe Manana
Added to misc-next, thanks.
On Mon, Oct 22, 2018 at 7:07 PM Josef Bacik wrote:
>
> On Mon, Oct 22, 2018 at 10:09:46AM +0100, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > When we are writing out a free space cache, during the transaction commit
> > phase, we can end up in a deadlock which results in a stack
On Mon, Oct 22, 2018 at 10:09:46AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When we are writing out a free space cache, during the transaction commit
> phase, we can end up in a deadlock which results in a stack trace like the
> following:
>
> schedule+0x28/0x80
>
On Mon, Oct 22, 2018 at 07:48:30PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When we are writing out a free space cache, during the transaction commit
> phase, we can end up in a deadlock which results in a stack trace like the
> following:
>
> schedule+0x28/0x80
>
On 2018/10/23 上午4:02, Gervais, Francois wrote:
> Hi,
>
> I think I lost power on my btrfs disk and it looks like it is now in an
> unfunctional state.
What does the word "unfunctional" mean?
Unable to mount? Or what else?
>
> Any idea how I could debug that issue?
>
> Here is what I have:
On Sat, Oct 20, 2018 at 1:34 PM Filipe Manana wrote:
>
> On Sat, Oct 20, 2018 at 9:27 PM Liu Bo wrote:
> >
> > On Fri, Oct 19, 2018 at 7:09 PM Andrew Nelson
> > wrote:
> > >
> > > I am having an issue with btrfs resize in Fedora 28. I am attempting
> > > to enlarge my Btrfs partition. Every
22 matches
Mail list logo
