On Thu, Apr 23, 2015 at 02:05:48PM +0100, Filipe David Manana wrote:
Trying the current integration-4.1 branch, I ran into the following
during xfstests/btrfs/049:
Ugh, I must not be waiting correctly in one of the inode cache writeout
sections. But I've run 049 a whole bunch of times
On 20/04/2015 11:51, Marc Cousin wrote:
On 31/03/2015 19:05, David Sterba wrote:
On Mon, Mar 30, 2015 at 05:09:52PM +0200, Marc Cousin wrote:
So it would be good to sample the active threads and see where it's
spending the time. It could be the somewhere in the rb-tree representing
extents,
On Thu, Apr 23, 2015 at 4:17 PM, Chris Mason c...@fb.com wrote:
On Thu, Apr 23, 2015 at 02:05:48PM +0100, Filipe David Manana wrote:
Trying the current integration-4.1 branch, I ran into the following
during xfstests/btrfs/049:
Ugh, I must not be waiting correctly in one of the inode
I've been hacking on https://github.com/csirac2/snazzer over the last
few months. It started out as a 20-line cron job, then a 50-line gist,
and now this thing that's obviously grown a little too much perhaps.
snazzer was initially written to help me maintain snapshots on a fleet
of VMs all using
On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
Pick one:
a) download the raw image and use that, but it will be a loopback file
with its own file system inside
or:
b) do the dnf/yum install root thing, and install it into a directory
tree.
I
On Thu, Apr 23, 2015 at 11:00:45AM +0800, Qu Wenruo wrote:
Although only RAID10 use sub_stripes, a hostile attack can modify chunk
tree and just add RAID10 bit to a single chunk.
Then btrfs_map_block will trigger a 0 division in kernel and destroy
everything.
Just add extra check when
On Wed, 22 Apr 2015 12:55:26 -0400, Chris Mason wrote:
Great to hear. I recommend just using my for-linus-4.1 branch, since it
has all the good things in one place.
Even with the latest patch for xfstests/049 I reproducibly get:
[ 405.052123]
On Thu, Apr 23, 2015 at 09:31:21AM +0800, Qu Wenruo wrote:
Current btrfs only support CRC32 checksum, and if csum_type is 1, we
will get 0 csum size, causing 0 division later destroy the whole kernel.
Or csum_type is later than 1, we will get data from other random memory
causing more problem.
On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
Pick one:
a) download the raw image and use that, but it will be a loopback file
with its own file system inside
or:
b) do
On Monday 20 Apr 2015 13:33:16 xuw2...@gmail.com wrote:
From: George Wang xuw2...@gmail.com
PPC64 arch use such following IOC values
\#define _IOC_NONE 1U
\#define _IOC_READ 2U
\#define _IOC_WRITE 4U
comparing to the default IOC values
\#define _IOC_NONE 0U
On Thu, Apr 23, 2015 at 7:36 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 19:29, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
When in /var/lib/machines/poppy:
root@hortensia ➤➤ machines/poppy # btrfs subvolume list .
ID 266 gen 98 top level 5 path rootvol
ID 268
On Thu, Apr 23, 2015 at 2:16 PM, Rich Freeman
r-bt...@thefreemanclan.net wrote:
On Mon, Apr 13, 2015 at 12:58 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
On Thu, 2 Apr 2015 10:17:47 -0400
Chris Mason c...@fb.com wrote:
Hi
On Thu, Apr 23, 2015 at 02:16:40PM -0400, Rich Freeman wrote:
On Mon, Apr 13, 2015 at 12:58 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
On Thu, 2 Apr 2015 10:17:47 -0400
Chris Mason c...@fb.com wrote:
Hi stable friends,
See also https://bugzilla.kernel.org/show_bug.cgi?id=97171
Running btrfs-progs v3.19.1
The btrfs-image attached to this bug causes the btrfs-userland tool to
use uninitialized memory and ultimately overwrite what seems to be
arbitrary memory locations, dying in the process. Reproduced on x86-64
On 04/23/2015 02:34 PM, Sasha Levin wrote:
On 04/23/2015 02:24 PM, Josh Boyer wrote:
On Thu, Apr 23, 2015 at 2:16 PM, Rich Freeman
r-bt...@thefreemanclan.net wrote:
On Mon, Apr 13, 2015 at 12:58 PM, Greg KH gre...@linuxfoundation.org
wrote:
On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman
On Thu, Apr 23, 2015 at 7:21 PM, arnaud gaboury
arnaud.gabo...@gmail.com wrote:
On Thu, Apr 23, 2015 at 7:12 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 19:00, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering
On 04/23/2015 12:34 PM, Holger Hoffstätte wrote:
kmem_cache_destroy btrfs_transaction: Slab cache still has objects
Josef has a fix for this, but the fix was causing other problems. It's
not a new bug, but we'll get it fixed up.
-chris
--
To unsubscribe from this list: send the line
Symlink restore needs this, but the cutpaste became
too complicated. Simplify everything.
Signed-off-by: Dan Merillat dan.meril...@gmail.com
---
cmds-restore.c | 53 ++---
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git
On Thu, 23.04.15 19:00, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
Pick one:
a) download the raw image and use that, but
Hello,
I had a 3 disk raid5 system with btrfs installed. Unfortunately one of the disks
crashed. Now I cannot mount the system any more, not even with the degraded
option. I suspect the failed disk to have a hw failure. I Think part of the
problem might be that I configured the system to not only
On Thu, 23.04.15 19:29, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
When in /var/lib/machines/poppy:
root@hortensia ➤➤ machines/poppy # btrfs subvolume list .
ID 266 gen 98 top level 5 path rootvol
ID 268 gen 100 top level 5 path var
ID 269 gen 101 top level 5 path etc
ID 271 gen 72
On 04/23/2015 02:24 PM, Josh Boyer wrote:
On Thu, Apr 23, 2015 at 2:16 PM, Rich Freeman
r-bt...@thefreemanclan.net wrote:
On Mon, Apr 13, 2015 at 12:58 PM, Greg KH gre...@linuxfoundation.org
wrote:
On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
On Thu, 2 Apr 2015
Hopefully this is sufficiently paranoid, tested with PATH_MAX length
symlinks, existing files, insufficient permissions, dangling symlinks.
I think I got the coding style correct this time, I'll fix and resend if
not.
Includes a trivial fix from my metadata patch, the documentation got
lost in
On Thu, Apr 23, 2015 at 7:12 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 19:00, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 14:18, arnaud gaboury
Hi,
More on my issue, I have uncorrectable errors
# btrfs scrub status /
scrub status for e11013b3-b244-4d1a-a9c7-3956db1a699c
scrub started at Thu Apr 23 19:07:45 2015 and finished after 372 seconds
total bytes scrubbed: 167.13GiB with 13 errors
error details: read=13
corrected
On Thu, Apr 23, 2015 at 4:48 PM, Filipe David Manana fdman...@gmail.com wrote:
On Thu, Apr 23, 2015 at 4:17 PM, Chris Mason c...@fb.com wrote:
On Thu, Apr 23, 2015 at 02:05:48PM +0100, Filipe David Manana wrote:
Trying the current integration-4.1 branch, I ran into the following
during
On 04/23/2015 03:43 PM, Filipe David Manana wrote:
On Thu, Apr 23, 2015 at 4:48 PM, Filipe David Manana fdman...@gmail.com
wrote:
On Thu, Apr 23, 2015 at 4:17 PM, Chris Mason c...@fb.com wrote:
On Thu, Apr 23, 2015 at 02:05:48PM +0100, Filipe David Manana wrote:
Trying the current
Hi Linus,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.1
I've been running these through a longer set of load tests because my
commits change the free space cache writeout. It fixes commit
stalls on large filesystems (~20T space used and up)
See also https://bugzilla.kernel.org/show_bug.cgi?id=97191
Running btrfs-progs v3.19.1
The btrfs-image attached to this bug causes the btrfs-userland tool to
overflow some data structures, leading to unallocated memory being
written to and read from. A segfault results shortly after. Reproduced
Hi,
This patch adds a 'du' subcommand to btrfs. 'btrfs fi du' will
calculate disk usage of the target files using fiemap. For individual
files, it will report a count of total bytes, and exclusive (not
shared) bytes. We also calculate a 'set shared' value which is
described below.
Each argument
This was lost in the cleanup of 71a559
Signed-off-by: Dan Merillat dan.meril...@gmail.com
---
Documentation/btrfs-restore.asciidoc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/btrfs-restore.asciidoc
b/Documentation/btrfs-restore.asciidoc
index 20fc366..89e0c87 100644
---
Restore symlinks, optionally with owner/times.
Signed-off-by: Dan Merillat dan.meril...@gmail.com
---
Documentation/btrfs-restore.asciidoc | 3 +
cmds-restore.c | 140 ++-
2 files changed, 140 insertions(+), 3 deletions(-)
diff --git
On Mon, Apr 13, 2015 at 12:58 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
On Thu, 2 Apr 2015 10:17:47 -0400
Chris Mason c...@fb.com wrote:
Hi stable friends,
Can you please backport this one to 3.19.y. It fixes a bug
- - posted on Thu, 23 Apr 2015 19:30:56 +0200 as excerpted:
Hello,
I had a 3 disk raid5 system with btrfs installed. Unfortunately one of
the disks crashed. Now I cannot mount the system any more, not even with
the degraded option. I suspect the failed disk to have a hw failure. I
Think
Martin Monperrus posted on Thu, 23 Apr 2015 20:05:16 +0200 as excerpted:
# btrfs scrub status /
scrub status for e11013b3-b244-4d1a-a9c7-3956db1a699c
scrub started at Thu Apr 23 19:07:45 2015
and finished after 372 seconds
total bytes scrubbed: 167.13GiB with 13 errors
error
Original Message
Subject: Re: [PATCH] btrfs: Check superblock csum type to avoid 0
division or array overflow.
From: David Sterba dste...@suse.cz
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2015年04月24日 00:16
On Thu, Apr 23, 2015 at 09:31:21AM +0800, Qu Wenruo wrote:
Old csum type check is wrong and can't catch csum_type 1(not supported).
Fix it to avoid hostile 0 division.
Reported-by: Lukas Lueg lukas.l...@gmail.com
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Changelog:
v2:
Fix existing codes other than adding new one.
---
fs/btrfs/ctree.h |
Although only RAID10 use sub_stripes, a hostile attack can modify chunk
tree and just add RAID10 bit to a single chunk.
Then btrfs_map_block will trigger a 0 division in kernel and destroy
everything.
Just add extra check when reading chunk from disk.
Reported-by: Lukas Lueg lukas.l...@gmail.com
IMHO Zeroing the RAID10 bit is not a good idea to repair.
As in that case, since the csum matched, normally we should trust
whatever we read. But if RAID10 bit is set but sub_stripe is still 0,
we are not sure whether the RAID10 bit or the sub_stripe value is wrong.
So what we know is,
I didn't check but repair should be made able to fix this situation
on an existing fs fairly easily by zeroing the BLOCK_GROUP_RAID10-bit
in case sub_stripes is zero or some unreasonable number and set the
bit in case sub_stripes has a reasonable, small value.
2015-04-23 5:00 GMT+02:00 Qu Wenruo
On 04/23/2015 08:45 AM, Filipe David Manana wrote:
On Wed, Apr 22, 2015 at 5:55 PM, Chris Mason c...@fb.com wrote:
On 04/22/2015 12:37 PM, Holger Hoffstätte wrote:
On Wed, 22 Apr 2015 18:09:18 +0200, Lutz Vieweg wrote:
On 04/13/2015 09:52 PM, Chris Mason wrote:
Large filesystems with lots of
On 04/23/2015 08:52 AM, Chris Mason wrote:
On 04/23/2015 08:45 AM, Filipe David Manana wrote:
On Wed, Apr 22, 2015 at 5:55 PM, Chris Mason c...@fb.com wrote:
On 04/22/2015 12:37 PM, Holger Hoffstätte wrote:
On Wed, 22 Apr 2015 18:09:18 +0200, Lutz Vieweg wrote:
On 04/13/2015 09:52 PM, Chris
On Thu, Apr 23, 2015 at 1:52 PM, Chris Mason c...@fb.com wrote:
On 04/23/2015 08:45 AM, Filipe David Manana wrote:
On Wed, Apr 22, 2015 at 5:55 PM, Chris Mason c...@fb.com wrote:
On 04/22/2015 12:37 PM, Holger Hoffstätte wrote:
On Wed, 22 Apr 2015 18:09:18 +0200, Lutz Vieweg wrote:
On
On Wed, Apr 22, 2015 at 12:53 PM, David Sterba dste...@suse.cz wrote:
Applied, thanks.
In future patches, please stick to the coding style used in progs ([1]),
I've fixed spacing around =, comments and moved declarations before
the statements.
[1]
There's a race between releasing extent buffers that are flagged as stale
and recycling them that makes us it the following BUG_ON at
btrfs_release_extent_buffer_page:
BUG_ON(extent_buffer_under_io(eb))
The BUG_ON is triggered because the extent buffer has the flag
EXTENT_BUFFER_DIRTY set as
On Thu, 23 Apr 2015 11:28:48 +0100, Filipe Manana wrote:
There's a race between releasing extent buffers that are flagged as stale
and recycling them that makes us it the following BUG_ON at
btrfs_release_extent_buffer_page:
BUG_ON(extent_buffer_under_io(eb))
The BUG_ON is triggered
On Thu, Apr 23, 2015 at 1:50 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
Not sure what I did wrong, but I can't install/boot my nspawn container.
Here is my setup:
Archlinux box- updated
1- created 3 btrfs
On Thu, Apr 23, 2015 at 2:00 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 14:57, Andrei Borzenkov (arvidj...@gmail.com) wrote:
On Thu, Apr 23, 2015 at 2:50 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 13:45, arnaud gaboury
On 04/23/2015 01:16 PM, Holger Hoffstätte wrote:
On Thu, 23 Apr 2015 11:28:48 +0100, Filipe Manana wrote:
There's a race between releasing extent buffers that are flagged as stale
and recycling them that makes us it the following BUG_ON at
btrfs_release_extent_buffer_page:
On Wed, Apr 22, 2015 at 5:55 PM, Chris Mason c...@fb.com wrote:
On 04/22/2015 12:37 PM, Holger Hoffstätte wrote:
On Wed, 22 Apr 2015 18:09:18 +0200, Lutz Vieweg wrote:
On 04/13/2015 09:52 PM, Chris Mason wrote:
Large filesystems with lots of block groups can suffer long stalls during
commit
On Thu, 23 Apr 2015 13:34:15 +0100, Filipe Manana wrote:
On 04/23/2015 01:16 PM, Holger Hoffstätte wrote:
On Thu, 23 Apr 2015 11:28:48 +0100, Filipe Manana wrote:
There's a race between releasing extent buffers that are flagged as stale
and recycling them that makes us it the following
On 04/23/2015 02:22 PM, Holger Hoffstätte wrote:
On Thu, 23 Apr 2015 13:34:15 +0100, Filipe Manana wrote:
On 04/23/2015 01:16 PM, Holger Hoffstätte wrote:
On Thu, 23 Apr 2015 11:28:48 +0100, Filipe Manana wrote:
There's a race between releasing extent buffers that are flagged as stale
On Thu, 23 Apr 2015 14:43:40 +0100, Filipe Manana wrote:
I don't think a lock followed by unlock without nothing in between (be
it a spinlock, mutex, or any other kind of lock) will be seen by the
compiler as a nop. Pretty sure I've seen this pattern being done in the
No, I didn't say they
On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
Not sure what I did wrong, but I can't install/boot my nspawn container.
Here is my setup:
Archlinux box- updated
1- created 3 btrfs subvol on /dev/sdb1 (SSD). The goal is to manage
snapshots easily.
no nested
On Thu, 23.04.15 14:57, Andrei Borzenkov (arvidj...@gmail.com) wrote:
On Thu, Apr 23, 2015 at 2:50 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
Not sure what I did wrong, but I can't install/boot my nspawn
Not sure what I did wrong, but I can't install/boot my nspawn container.
Here is my setup:
Archlinux box- updated
1- created 3 btrfs subvol on /dev/sdb1 (SSD). The goal is to manage
snapshots easily.
no nested subvol.
--
# btrfs subvolume list .
ID 266 gen
On Thu, Apr 23, 2015 at 2:50 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
Not sure what I did wrong, but I can't install/boot my nspawn container.
Here is my setup:
Archlinux box- updated
1- created 3 btrfs
Dan Merillat posted on Thu, 23 Apr 2015 12:47:29 -0400 as excerpted:
Hopefully this is sufficiently paranoid, tested with PATH_MAX length
symlinks, existing files, insufficient permissions, dangling symlinks. I
think I got the coding style correct this time, I'll fix and resend if
not.
58 matches
Mail list logo
