On 09/25/2017 06:11 PM, linux-bt...@oh3mqu.pp.hyper.fi wrote as excerpted:
> After a long googling (about more complex situations) I suddenly
> noticed "device sdb" WTF??? Filesystem is mounted from /dev/md3 (sdb
> is part of that mdraid) so btrfs should not even know anything about
> that /dev/sd
1/3 fixes a bug which failed to reset writable when sprouting failed
2/3 is cleanup and preparatory to fix 3/3
3/3 fixes BUG_ON in btrfs_init_new_device()
v2:
add commit log to 1/3
do not consolidate btrfs_abort_transaction() in 2/3
Anand Jain (3):
btrfs: undo writable when sprouting fails
Moves btrfs_abort_transaction() to the error goto and renames
error_trans to error_sysfs. This is a preparatory patch to
remove the BUG_ON() in btrfs_init_new_device().
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a
Instead of BUG_ON return error to the caller. And handle the fail
condition by calling the abort transaction through the error path.
Signed-off-by: Anand Jain
---
v2: do not consolidate btrfs_abort_transaction()
fs/btrfs/volumes.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
When new device is being added to seed FS, seed FS is marked writable,
but when we fail to bring in the new device, we missed to undo the
writable part. This patch fixes it.
Signed-off-by: Anand Jain
---
v2: add commit log
fs/btrfs/volumes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/
The
sysfs rm stands though
This is a preparatory patch for 3/3, at BUG_ON it needs an exit
without the btrfs_sysfs_add_device_link() part.
-Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo
On 09/26/2017 03:57 PM, Anand Jain wrote:
The
sysfs rm stands though
This is a preparatory patch for 3/3, at BUG_ON it needs an exit
without the btrfs_sysfs_add_device_link() part.
typo
s/btrfs_sysfs_add_device_link/btrfs_sysfs_rm_device_link/
-Anand
--
To unsubscribe from this lis
linux-btrfs posted on Mon, 25 Sep 2017 19:11:01 +0300 as excerpted:
Three points first off:
1) Please use a name other than "linux-btrfs". That can remain the email
address, but a name to go with it would be nice. (You can see how my
name and email address differ, for instance.)
2) Please do
On 26.09.2017 10:57, Anand Jain wrote:
>
>> The
>> sysfs rm stands though
>
> This is a preparatory patch for 3/3, at BUG_ON it needs an exit
> without the btrfs_sysfs_add_device_link() part.
In this case I'd rather you have this change in 3/3, because on its own
it doesn't really make sense
1/2 fixes a bug which failed to reset writable when sprouting failed
2/2 fixes BUG_ON in btrfs_init_new_device()
Anand Jain (2):
btrfs: undo writable when sprouting fails
btrfs: fix BUG_ON in btrfs_init_new_device()
fs/btrfs/volumes.c | 16 +++-
1 file changed, 11 insertions(+),
Instead of BUG_ON return error to the caller. And handle the fail
condition by calling the abort transaction and going through the
error path.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/volumes.c b/
When new device is being added to seed FS, seed FS is marked writable,
but when we fail to bring in the new device, we missed to undo the
writable part. This patch fixes it.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/volumes.c
Dear Qu,
thanks for your reply.
On 09/25/2017 12:19 PM, Qu Wenruo wrote as excerpted:
> Even no dmesg output using tty or netconsole?
And thanks for the pointer to netconsole, I tried that one.
No success. I set netconsole up, verified it worked, started a scrub,
the machine went away after a co
The
sysfs rm stands though
This is a preparatory patch for 3/3, at BUG_ON it needs an exit
without the btrfs_sysfs_add_device_link() part.
In this case I'd rather you have this change in 3/3, because on its own
it doesn't really make sense and cannot easily be figured out if doing
git bla
1/2 fixes a bug which failed to reset writable when sprouting failed
2/2 fixes BUG_ON in btrfs_init_new_device()
Anand Jain (2):
btrfs: undo writable when sprouting fails
btrfs: fix BUG_ON in btrfs_init_new_device()
fs/btrfs/volumes.c | 16 +++-
1 file changed, 11 insertions(+),
When new device is being added to seed FS, seed FS is marked writable,
but when we fail to bring in the new device, we missed to undo the
writable part. This patch fixes it.
Signed-off-by: Anand Jain
---
v3: none
v2: add commit log
fs/btrfs/volumes.c | 2 ++
1 file changed, 2 insertions(+)
dif
Instead of BUG_ON return error to the caller. And handle the fail
condition by calling the abort transaction and going through the
error path.
Signed-off-by: Anand Jain
---
v2: do not consolidate btrfs_abort_transaction()
v3: meld 2/3 and 3/3 from v2
fs/btrfs/volumes.c | 14 +-
1 fi
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of David Sterba
> Sent: Sunday, 24 September 2017 11:46 PM
> To: Liu Bo
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH 1/2] Btrfs: fix kernel oops while reading c
On 2017年09月26日 16:34, Lukas Pirl wrote:
Dear Qu,
thanks for your reply.
On 09/25/2017 12:19 PM, Qu Wenruo wrote as excerpted:
Even no dmesg output using tty or netconsole?
And thanks for the pointer to netconsole, I tried that one.
No success. I set netconsole up, verified it worked, start
On Fri, Sep 22, 2017 at 05:21:27PM -0600, Liu Bo wrote:
> We had a bug in btrfs compression code which could end up with a
> kernel panic.
>
> This is adding a regression test for the bug and I've also sent a
> kernel patch to fix the bug.
>
> The patch is "Btrfs: fix kernel oops while reading co
Hi Qu,
On 09/26/2017 10:51 AM, Qu Wenruo wrote as excerpted:
> This make things more weird.
> Just in case, are you executing offline scrub by "btrfs scrub start
> --offline "
Yes. I even got some output (pretty sure the last lines are missing due
to the crash):
WARNING: Offline scrub doesn't su
On 12.09.2017 00:15, Timofey Titovets wrote:
> Remove dead assigment of num_bytes
>
> Also as num_bytes only used in will_compress block as
> copy of total_in just replace that with total_in and drop num_bytes entire
>
> Signed-off-by: Timofey Titovets
Reviewed-by: Nikolay Borisov
> ---
>
When quota disabled, btrfs qgroup show exit with a error message,
but the allocated memory is not freed.
By the way, this bug marked as issue#20 in github.
Signed-off-by: Gu Jinxiang
---
cmds-qgroup.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/cmds-qgroup.c b/c
On 2017年09月26日 17:26, Lukas Pirl wrote:
Hi Qu,
On 09/26/2017 10:51 AM, Qu Wenruo wrote as excerpted:
This make things more weird.
Just in case, are you executing offline scrub by "btrfs scrub start
--offline "
Yes. I even got some output (pretty sure the last lines are missing due
to the cr
On Tue, Sep 26, 2017 at 05:28:31PM +0800, Gu Jinxiang wrote:
> When quota disabled, btrfs qgroup show exit with a error message,
> but the allocated memory is not freed.
>
> By the way, this bug marked as issue#20 in github.
>
> Signed-off-by: Gu Jinxiang
Applied, thanks.
--
To unsubscribe from
On Tue, Sep 26, 2017 at 08:41:27AM +, Paul Jones wrote:
> > -Original Message-
> > From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> > ow...@vger.kernel.org] On Behalf Of David Sterba
> > Sent: Sunday, 24 September 2017 11:46 PM
> > To: Liu Bo
> > Cc: linux-btrfs@vger.kern
On 09/26/2017 11:36 AM, Qu Wenruo wrote as excerpted:
> This is strange, this means that we can't find a chunk map for a 72K
> length data extent.
>
> Either the new mapper code has some bug, or it's a big problem.
> But I think it's more possible for former case.
>
> Would you please try to dump
On Tue, Sep 26, 2017 at 08:28:25AM +0800, Qu Wenruo wrote:
>
>
> On 2017年09月25日 23:45, David Sterba wrote:
> > On Wed, Aug 23, 2017 at 04:57:58PM +0900, Qu Wenruo wrote:
> >> Add extra checker for item with EXTENT_DATA type.
> >> This checks the following thing:
> >> 0) Key offset
> >> All ke
On 26.09.2017 11:47, Anand Jain wrote:
> 1/2 fixes a bug which failed to reset writable when sprouting failed
> 2/2 fixes BUG_ON in btrfs_init_new_device()
>
> Anand Jain (2):
> btrfs: undo writable when sprouting fails
> btrfs: fix BUG_ON in btrfs_init_new_device()
Reviewed-by: Nikolay Bor
On Tue, Sep 26, 2017 at 08:46:29AM +0800, Qu Wenruo wrote:
> On 2017年09月26日 08:28, Qu Wenruo wrote:
> > On 2017年09月25日 23:45, David Sterba wrote:
> >> On Wed, Aug 23, 2017 at 04:57:58PM +0900, Qu Wenruo wrote:
> >>> Add extra checker for item with EXTENT_DATA type.
> >>> This checks the following t
On 2017年09月26日 19:50, Lukas Pirl wrote:
On 09/26/2017 11:36 AM, Qu Wenruo wrote as excerpted:
This is strange, this means that we can't find a chunk map for a 72K
length data extent.
Either the new mapper code has some bug, or it's a big problem.
But I think it's more possible for former case
On 2017年09月26日 20:05, David Sterba wrote:
On Tue, Sep 26, 2017 at 08:28:25AM +0800, Qu Wenruo wrote:
On 2017年09月25日 23:45, David Sterba wrote:
On Wed, Aug 23, 2017 at 04:57:58PM +0900, Qu Wenruo wrote:
Add extra checker for item with EXTENT_DATA type.
This checks the following thing:
0) Ke
On 2017年09月26日 20:13, David Sterba wrote:
On Tue, Sep 26, 2017 at 08:46:29AM +0800, Qu Wenruo wrote:
On 2017年09月26日 08:28, Qu Wenruo wrote:
On 2017年09月25日 23:45, David Sterba wrote:
On Wed, Aug 23, 2017 at 04:57:58PM +0900, Qu Wenruo wrote:
Add extra checker for item with EXTENT_DATA type.
On 2017年09月26日 16:41, Anand Jain wrote:
Instead of BUG_ON return error to the caller. And handle the fail
condition by calling the abort transaction and going through the
error path.
Signed-off-by: Anand Jain
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
fs/btrfs/volumes.c | 14 +-
On 2017年09月26日 16:41, Anand Jain wrote:
When new device is being added to seed FS, seed FS is marked writable,
but when we fail to bring in the new device, we missed to undo the
writable part. This patch fixes it.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 2 ++
1 file changed, 2 i
On 2017年09月26日 13:45, Misono, Tomohiro wrote:
Change seen_fsid to hold fd and DIR* in order to keep access to each fs.
This will be used for 'subvol delete --commit-after'.
It is already quite good, good enough for the fix.
However just a small point can be further enhanced, commended below.
On 2017年09月26日 13:46, Misono, Tomohiro wrote:
Fix subvol del --commit-after to work properly:
- SYNC ioctl will be issued even when last delete is failed
- SYNC ioctl will be issued on each file system only once in the end
To achieve this, get_fsid() and add_seen_fsid() is called after eac
On 2017年09月26日 13:44, Misono, Tomohiro wrote:
Fix subvol del --commit-after to work properly:
- SYNC ioctl will be issued even when last delete is failed
- SYNC ioctl will be issued on each file system only once in the end
To achieve this, each deleted subvol's (parent's) fsid is checked e
btrfs_update_root can fail for any number of reasons, however the only error
handling we do is to revert the modified flags, yet we do not abort the
transaction but proceed to commit it. Fix this by explicitly checking if the
update root routine has failed and abort the transaction.
Fixes: 0caa102
Currently when a read-only snapshot is received and subsequently its ro property
is set to false i.e. switched to rw-mode the received_uuid of that subvol
remains
intact. However, once the received volume is switched to RW mode we cannot
guaranteee that it contains the same data, so it makes sense
I accidentally filled my OS drive with a copy of itself? The problem
is, /data/ is a separate pool from the OS drive. And now it looks like
I can't erase it? I don't even know how I got here. All I did was "dd
if=/dev/sda of=/data/Backup/backup-new.img && mv
/data/Backup/backup-new.img /data/Backup
On Tue, Sep 26, 2017 at 08:49:55PM +0800, Qu Wenruo wrote:
> > Yeah something like that. And also make it a function, unless we're
> > going to use some macro magic (I'm not sure about that yet).
> >
> > Schematically:
> >
> > btrfs_report_corruption(fs_info, EXTENT_ITEM, "file item type is unkno
So somehow my @ and @home subvolumes became mounted at /data/Backup in
addition to their normal locations (/ and /home). So when I used 'dd'
I was outputting to my OS drive instead of my data pool. How did this
happen? How do I undo it? I'll try restarting now, but I'll await
further responses befo
Looking at the Phoronix benchmark here:
https://www.phoronix.com/scan.php?page=article&item=linux414-bcache-
raid&num=2
I think it might be idle hopes to think bcache can be used as a ssd cache
for btrfs to significantly improve performance.. True, the benchmark is
using ext.
But the most impo
On Tue, Sep 26, 2017 at 05:27:41PM +0300, Nikolay Borisov wrote:
> btrfs_update_root can fail for any number of reasons, however the only error
> handling we do is to revert the modified flags, yet we do not abort the
> transaction but proceed to commit it.
AFAICS btrfs_update_root aborts the tran
On Tue, Sep 26, 2017 at 08:57:47PM +0800, Qu Wenruo wrote:
>
>
> On 2017年09月26日 16:41, Anand Jain wrote:
> > When new device is being added to seed FS, seed FS is marked writable,
> > but when we fail to bring in the new device, we missed to undo the
> > writable part. This patch fixes it.
> >
>
On Tue, 26 Sep 2017 16:50:00 + (UTC)
Ferry Toth wrote:
> https://www.phoronix.com/scan.php?page=article&item=linux414-bcache-
> raid&num=2
>
> I think it might be idle hopes to think bcache can be used as a ssd cache
> for btrfs to significantly improve performance..
My personal real-world
Am Tue, 26 Sep 2017 23:33:19 +0500
schrieb Roman Mamedov :
> On Tue, 26 Sep 2017 16:50:00 + (UTC)
> Ferry Toth wrote:
>
> > https://www.phoronix.com/scan.php?page=article&item=linux414-bcache-
> > raid&num=2
> >
> > I think it might be idle hopes to think bcache can be used as a ssd
> > cac
On 2017-09-26 12:50, Ferry Toth wrote:
Looking at the Phoronix benchmark here:
https://www.phoronix.com/scan.php?page=article&item=linux414-bcache-
raid&num=2
I think it might be idle hopes to think bcache can be used as a ssd cache
for btrfs to significantly improve performance.. True, the ben
On Tue, Sep 26, 2017 at 11:33:19PM +0500, Roman Mamedov wrote:
> On Tue, 26 Sep 2017 16:50:00 + (UTC)
> Ferry Toth wrote:
>
> > https://www.phoronix.com/scan.php?page=article&item=linux414-bcache-
> > raid&num=2
> >
> > I think it might be idle hopes to think bcache can be used as a ssd cach
We pass in a pointer in our send arg struct, this means the struct size doesn't
match with 32bit user space and 64bit kernel space. Fix this by adding a compat
mode and doing the appropriate conversion.
Signed-off-by: Josef Bacik
---
fs/btrfs/ioctl.c | 6 +-
fs/btrfs/send.c
> i run a few performance tests comparing mdadm, hardware raid
> and the btrfs raid.
Fantastic beginning already! :-)
> I noticed that the performance
I have seen over the years a lot of messages like this where
there is a wanton display of amusing misuses of terminology, of
which the misuse of
Hello!
I came across noting some kernel messages which seem to be related to
btrfs, should I worry?
I'm currently running scrub on the device now.
inode-resolve points to an unimportant, easily recoverable file:
$ sudo btrfs inspect-internal inode-resolve -v 1229624
/mnt/btrfs-pool/gentoo/usr/
Hi,
I just had my laptop hit the out of space kernel oops which it kinda
hard to recover from
Everything states "out of disk" even with 20 gigs free (both according
to df and btrfs fi df)
So I'm suspecting that i need to run btrfs check on it to recover the
lost space (i have mounted it with cle
Op Tue, 26 Sep 2017 15:52:44 -0400, schreef Austin S. Hemmelgarn:
> On 2017-09-26 12:50, Ferry Toth wrote:
>> Looking at the Phoronix benchmark here:
>>
>> https://www.phoronix.com/scan.php?page=article&item=linux414-bcache-
>> raid&num=2
>>
>> I think it might be idle hopes to think bcache can
Am Wed, 27 Sep 2017 00:45:04 +0200
schrieb Ian Kumlien :
> I just had my laptop hit the out of space kernel oops which it kinda
> hard to recover from
>
> Everything states "out of disk" even with 20 gigs free (both according
> to df and btrfs fi df)
You should run balance from time to time. I c
On Wed, Sep 27, 2017 at 12:21:55AM +0200, Kai Krakow wrote:
> Hello!
>
> I came across noting some kernel messages which seem to be related to
> btrfs, should I worry?
>
> I'm currently running scrub on the device now.
>
> inode-resolve points to an unimportant, easily recoverable file:
>
> $ s
tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
new-kill-btree-inode
head: f2213041f761c4972696a8dabfad3c8bac9ffde2
commit: f2213041f761c4972696a8dabfad3c8bac9ffde2 [22/22] btrfs: fix send ioctl
on 32bit with 64bit kernel
config: i386-randconfig-x000-201739 (attache
On Tue, Sep 26, 2017 at 05:02:36PM +0800, Eryu Guan wrote:
> On Fri, Sep 22, 2017 at 05:21:27PM -0600, Liu Bo wrote:
> > We had a bug in btrfs compression code which could end up with a
> > kernel panic.
> >
> > This is adding a regression test for the bug and I've also sent a
> > kernel patch to
tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
new-kill-btree-inode
head: f2213041f761c4972696a8dabfad3c8bac9ffde2
commit: f2213041f761c4972696a8dabfad3c8bac9ffde2 [22/22] btrfs: fix send ioctl
on 32bit with 64bit kernel
config: x86_64-randconfig-x018-201739 (attac
On Tue, Sep 26, 2017 at 04:37:52PM -0700, Liu Bo wrote:
> On Tue, Sep 26, 2017 at 05:02:36PM +0800, Eryu Guan wrote:
> > On Fri, Sep 22, 2017 at 05:21:27PM -0600, Liu Bo wrote:
> > > We had a bug in btrfs compression code which could end up with a
> > > kernel panic.
> > >
> > > This is adding a r
On 2017/09/26 22:08, Qu Wenruo wrote:
>
>
> On 2017年09月26日 13:45, Misono, Tomohiro wrote:
>> Change seen_fsid to hold fd and DIR* in order to keep access to each fs.
>> This will be used for 'subvol delete --commit-after'.
>
> It is already quite good, good enough for the fix.
>
> However just
On 2017年09月27日 08:42, Misono, Tomohiro wrote:
On 2017/09/26 22:08, Qu Wenruo wrote:
On 2017年09月26日 13:45, Misono, Tomohiro wrote:
Change seen_fsid to hold fd and DIR* in order to keep access to each fs.
This will be used for 'subvol delete --commit-after'.
It is already quite good, good e
Fix subvol del --commit-after to work properly:
- SYNC ioctl will be issued even when last delete is failed
- SYNC ioctl will be issued on each file system only once in the end
To achieve this, each deleted subvol's (parent's) fsid is checked each
time. If the fsid is seen for the first time, it
Current code is reversed in --commit-after and --commit-each operation.
i.e. --commit-after means --commit-each actually. This patch fix this
and also introduces enum type for more readable code.
Signed-off-by: Tomohiro Misono
Reviewed-by: Qu Wenruo
---
cmds-subvolume.c | 13 +++--
1 fi
Make get_fsid() to a common function.
This will be used for 'subvol delete --commit-after'.
Signed-off-by: Tomohiro Misono
Reviewed-by: Qu Wenruo
---
cmds-property.c | 30 --
utils.c | 31 +++
utils.h | 1 +
3 files change
Make is_seen_fsid()/add_seen_fsid()/free_seen_fsid() to common functions.
This will be used for 'subvol delete --commit-after'.
Signed-off-by: Tomohiro Misono
Reviewed-by: Qu Wenruo
---
cmds-filesystem.c | 88 ---
utils.c | 70 ++
Change seen_fsid to hold fd and DIR* in order to keep access to each fs.
This will be used for 'subvol delete --commit-after'.
Signed-off-by: Tomohiro Misono
Reviewed-by: Qu Wenruo
---
cmds-filesystem.c | 4 ++--
utils.c | 6 +-
utils.h | 5 -
3 files changed, 11 ins
Fix subvol del --commit-after to work properly:
- SYNC ioctl will be issued even when last delete is failed
- SYNC ioctl will be issued on each file system only once in the end
To achieve this, get_fsid() and add_seen_fsid() is called after each delete
to keep only one fd for each fs.
In the en
Lowmem check does not skip invalid type in extent_inline_ref then
calls btrfs_extent_inline_ref_size(type) which causes crash.
Error:
$ btrfs check --mode=lowmem /tmp/data_small
Checking filesystem on /tmp/data_small
UUID: ee205d69-8724-4aa2-a4f5-bc8558a62169
checking extents
ERROR: extent[209715
In original check mode(without option "--repair"), check_extent_refs()
always returns 0.
Add a variable @error to record status while checking extents.
At the end of check_extent_refs(), let it return -EIO if @error is
nonzero.
Example:
$ btrfs check bad-extent-inline-ref-type.raw
Checking filesy
The head three patches is independent from later two.
Include:
1) Let check_extent_refs() return error instead of 0 if something wrong
is found in original mode.
2) repair_root_items() should be called before any repair. Put it
before do_check_chunks_and_extents();
3) Error status should not
Return value of repair_root_items():
<0 on error
=0 does nothing
>0 if repair is enable, N roots is repaired;
else N roots is corrupted.
In the repair mode, there should be no error if return value is bigger
than 0.
Signed-off-by: Su Yue
---
cmds-check.c | 2 +-
1 file changed, 1 insertion(+
This case is for avoiding crash in lowmem check mode.
Field type of extent_inline_ref in an extent is corrupted.
Signed-off-by: Su Yue
---
.../bad-extent-inline-ref-type.raw.xz | Bin 0 -> 17144 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644
tests/fs
The Annotation of repair_root_items():
"This must be run before any other repair code - not doing it so,
makes other repair code delete or modify backrefs in the extent tree
for example, which will result in an inconsistent fs after repairing
the root items."
However, the rule was broken by commit
75 matches
Mail list logo
