And now I was able to reproduce on a second machine. The main
difference between the affected and the unaffected systems is
initramfs. On the affected systems, I don't use one.
In this test of with or without initramfs script. I guess the kernel
remain same at 3.17-rc3 and above
On the wo
On 09/16/2014 11:27 PM, Chris Murphy wrote:
>
> Try to mount normally, then with -o recovery, then with -o ro,recovery.
> Include dmesg showing any messages that appear for these attempts.
Thank you,
Please find below the messages shown during a normal mount and a mount
with -o ro,recovery.
On Mon, Sep 15, 2014 at 12:30:23AM -0700, beh...@converseincode.com wrote:
> From: Behan Webster
>
> Add a macro which replaces the use of a Variable Length Array In Struct
> (VLAIS)
> with a C99 compliant equivalent. This macro instead allocates the appropriate
> amount of memory using an char
Hi Chris,
---
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index e9676a4..1224b61 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -533,7 +533,7 @@ static noinline int device_list_add(const char *path,
* the btrfs dev scan cli, after FS has been mounted
Hi,
Could anyone help to review this patch? Thanks!
Regards,
Xing Gu
On 05/30/2014 04:52 PM, Xing Gu wrote:
> Regression test for resizing 'thread_pool' when remount the fs.
>
> Signed-off-by: Xing Gu
> ---
> tests/btrfs/055 | 55
> +++
On 17/09/14 12:22, Herbert Xu wrote:
> On Mon, Sep 15, 2014 at 12:30:23AM -0700, beh...@converseincode.com wrote:
>> From: Behan Webster
>>
>> Add a macro which replaces the use of a Variable Length Array In Struct
>> (VLAIS)
>> with a C99 compliant equivalent. This macro instead allocates the ap
On 2014-09-16 16:57, Chris Murphy wrote:
>
> On Sep 16, 2014, at 8:40 AM, Austin S Hemmelgarn wrote:
>
>> Based on the kernel messages, the primary issue is log corruption, and
>> in theory btrfs-zero-log should fix it.
>
> Can you provide a complete dmesg somewhere for this initial failure, ju
On Wed, Sep 17, 2014 at 02:15:40PM +0300, Dmitry Kasatkin wrote:
> On 17/09/14 12:22, Herbert Xu wrote:
> > On Mon, Sep 15, 2014 at 12:30:23AM -0700, beh...@converseincode.com wrote:
> >> From: Behan Webster
> >>
> >> Add a macro which replaces the use of a Variable Length Array In Struct
> >> (V
On 09/17/2014 05:47 AM, Anand Jain wrote:
>
> Hi Chris,
>
>
>>> ---
>>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>>> index e9676a4..1224b61 100644
>>> --- a/fs/btrfs/volumes.c
>>> +++ b/fs/btrfs/volumes.c
>>> @@ -533,7 +533,7 @@ static noinline int device_list_add(const char
>>
The tracepoint of extent map doesn't parse @flag correctly, we set @flag via
set_bit(), so we need to parse it on a bit bias.
Also add the missing flag, EXTENT_FLAG_FS_MAPPING.
Signed-off-by: Liu Bo
---
include/trace/events/btrfs.h | 13 +++--
1 file changed, 7 insertions(+), 6 deletion
On 09/15/2014 03:30 AM, beh...@converseincode.com wrote:
> From: Vinícius Tinti
>
> Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
> compliant equivalent. This is the original VLAIS struct.
>
> struct {
> struct shash_desc shash;
> char ctx[crypto_shash_de
Trying to reproduce a log enospc bug I hit a panic in the async reclaim code
during log replay. This is because we use fs_info->fs_root as our root for
shrinking and such. Technically we can use whatever root we want, but let's
just not allow async reclaim while we're doing log replay. Thanks,
kernel: 3.16.2
On Tue, Sep 16, 2014 at 04:57:42PM -0700, Marc MERLIN wrote:
> I have a filtered log showing any system call that took more than 1 sec,
> that list is small:
> http://marc.merlins.org/tmp/btrfs_receive.log
>
> Most of the time is apparently just death by a thousand cuts of many
> m
On 09/17/14 04:30, Herbert Xu wrote:
On Wed, Sep 17, 2014 at 02:15:40PM +0300, Dmitry Kasatkin wrote:
On 17/09/14 12:22, Herbert Xu wrote:
On Mon, Sep 15, 2014 at 12:30:23AM -0700, beh...@converseincode.com wrote:
From: Behan Webster
Add a macro which replaces the use of a Variable Length Ar
On Wed, Sep 17, 2014 at 04:54:48AM +0100, Al Viro wrote:
> On Tue, Sep 16, 2014 at 11:05:00PM -0400, Shea Levy wrote:
> > Hi all,
> >
> > What work would be required to mark btrfs_fs_type with FS_USERNS_MOUNT
> > so that btrfs images can be mounted by unprivileged users within a user
> > namespace
This:
# truncate --size=8g
# dd if=/dev/zero of=file conv=notrunc bs=4 seek=16384 count=1
# valgrind ./btrfs rescue super-recover file -v
yields:
==4604== Memcheck, a memory error detector
==4604== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4604== Using Valgrind-3.8.1 and
On 9/17/14 12:00 PM, Eric Sandeen wrote:
> This:
>
> # truncate --size=8g
oops, s/b:
# truncate --size=8g file
> # dd if=/dev/zero of=file conv=notrunc bs=4 seek=16384 count=1
> # valgrind ./btrfs rescue super-recover file -v
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Wed, Sep 17, 2014 at 08:00:02AM -0700, Marc MERLIN wrote:
> kernel: 3.16.2
Grumble, I messed up the subject line.
I meant that COW on virtual disk images causes the problems described in the
previous Email.
Obviously I already know that COW on disk images wasn't ideal, but the
effects in 3.16 a
I know that sounds weird, but here's my scenario:
- Create a RAID1 filesystem (both data and metadata) using 2 same-sized
external USB drives
- Copy data (backup of other filesystem) onto this new filesystem
- Dismount the filesystem
- Split up the drives (keep one at home, move one to offsite bac
> Does/should a balance imply removal of missing devices (as long as
the minimum number of devices are still available)?
That's a really good question. As a user I would expect it to balance
over remaining devices assuming you still have a complete picture.
Doing a device delete missing after
On Sep 17, 2014, at 3:06 AM, Tovo Rabemanantsoa
wrote:
>
> Sep 17 11:05:55 sdeeph1 kernel: [85381.548215] parent transid verify
> failed on 24562568384512 wanted 255444 found 255446
> Sep 17 11:05:55 sdeeph1 kernel: [85381.548229] parent transid verify
> failed on 24562568384512 wanted 255444 f
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn wrote:
>
> Thanks for all the help.
Well, it's not much help. It seems possible to "corrupt" a primary superblock
that points to a corrupt tree root, and use btrfs rescure super-recover to
replace it, and then mount should work. One thing I did
On Wed, Sep 17, 2014 at 10:13:01AM -0700, Alan Hagge wrote:
> I know that sounds weird, but here's my scenario:
There was similar thread [1] few days ago, you should take a look at it.
[1] https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg37144.html
Piotr Szymaniak.
--
I ten smród. D
On Sep 17, 2014, at 11:51 AM, Mark Murawski wrote:
> > Does/should a balance imply removal of missing devices (as long as the
> > minimum number of devices are still available)?
>
> That's a really good question. As a user I would expect it to balance over
> remaining devices assuming you st
Alan Hagge posted on Wed, 17 Sep 2014 10:13:01 -0700 as excerpted:
> I know that sounds weird, but here's my scenario:
>
> - Create a RAID1 filesystem (both data and metadata) using 2 same-sized
> external USB drives - Copy data (backup of other filesystem) onto this
> new filesystem - Dismount t
Chris Murphy posted on Wed, 17 Sep 2014 12:57:59 -0600 as excerpted:
> But I think you're onto something, that a good superblock can point to a
> corrupt tree root, and then not have a straight forward way to mount the
> good tree root. If I understand this correctly.
This is what I ran into myse
Austin S Hemmelgarn posted on Wed, 17 Sep 2014 07:23:46 -0400 as
excerpted:
> I've also discovered, when trying to use btrfs restore to copy out the
> data to a different system, that 3.14.1 restore apparently chokes on
> filesystem that have lzo compression turned on. It's reporting errors
> try
On Wed, Sep 17, 2014 at 09:12:14AM -0700, Zach Brown wrote:
> On Wed, Sep 17, 2014 at 04:54:48AM +0100, Al Viro wrote:
> > On Tue, Sep 16, 2014 at 11:05:00PM -0400, Shea Levy wrote:
> > > Hi all,
> > >
> > > What work would be required to mark btrfs_fs_type with FS_USERNS_MOUNT
> > > so that btrfs
Mark Murawski posted on Wed, 17 Sep 2014 13:51:51 -0400 as excerpted:
>> Does/should a balance imply removal of missing devices (as long as
>> the minimum number of devices are still available)?
>
> That's a really good question. As a user I would expect it to balance
> over remaining devices as
Hello everyone,
Some of you know about Rockstor already from an email I sent several
weeks ago. For others, It's the BTRFS powered NAS solution we've
developed and just made the 3.0 release available.
Besides software updates, we've also improved the distribution
infrastructure and the installer
From: Anand Jain
With the changes as in the previous patch, now scan_for_btrfs()
is an unused function. So delete it.
Signed-off-by: Anand Jain
---
utils.c | 15 ---
utils.h | 1 -
2 files changed, 16 deletions(-)
diff --git a/utils.c b/utils.c
index 0ae0475..0cd97c7 100644
--- a
From: Anand Jain
The libblkid scan method which was introduced later, will also
scan devices under /proc/partitions. So we don't have to do
the explicit scan of the same.
Remove the scan method BTRFS_SCAN_PROC.
Signed-off-by: Anand Jain
---
cmds-device.c | 5 ++---
cmds-filesystem.c | 10
*Note*: this handles the problem under umounted state,
the problem under mounted state is already fixed by Anand.
Steps to reproduce:
# mkfs.btrfs -f /dev/sda1
# btrfstune -S 1 /dev/sda1
# mount /dev/sda1 /mnt
# btrfs dev add /dev/sda2 /mnt
# umount
When runing restore under lzo compression, "bad compress length"
problems are encountered.
It is because there is a page align problem with the @decompress_lzo,
as follows:
|--| ||-| |--|...|--|
page ^page page
On Mon, 2014-09-01 at 15:25 +, Zooko Wilcox-OHearn wrote:
> I'm more than happy to try out patches and even focus my own brain on
> diagnosing it, if I can. I'm hoping to regain access to some of my
> files on my btrfs partition, and also I would enjoy helping get this
> improved. :-)
>
> So i
**
* WARNING: on-disk data format changes is introduced *
**
Before this patch, when use compression, prealloc space will never be used,
and any compression write into it will be cowed.
If we j
Before this patch, when replay_one_extent() find an existing file
extent item, btrfs will call read_extent_buffer() to read out the file
extent.
However it lacks enough check, and may read out the inline file extent
using the wrong size(currently it always uses
sizeof(btrfs_file_extent_item))
If a
On Wed, Sep 17, 2014 at 11:53:35AM +0800, Qu Wenruo wrote:
> The following commit enhanced the merge_extent_mapping() to reduce
> fragment in extent map tree, but it can't handle case which existing
> lies before map_start:
> 51f39 btrfs: Use right extent length when inserting overlap extent map.
>
Add support for nocow compressed write into preallocated range.
The main change is the following:
1) use disk_bytenr + data_offset to search csum
2) use offset + num_bytes - data_offset to judge if this is a valid
file extent.
3) add file extent item size check,
Since now regular file extent has 2
Add data_offset and data_len output for print_file_extent_item in
print-tree.c
WARNING: because the original output has word 'data' before 'offset',
to avoid confusion, remove the work 'data' before 'offset' and 'disk
bytenr'.
Signed-off-by: Qu Wenruo
---
print-tree.c | 14 ++
1 fil
Add basic nocow compressed write into preallocated range support in
mkfs and headers.
Now we can use mkfs to create a btrfs which supports nocow compressed
prealloc write.
Signed-off-by: Qu Wenruo
---
ctree.h | 69 -
mkfs.c | 2 +
What's the status on this patch? There have been at least a couple of bug
reports that this fixes, including
https://bugzilla.kernel.org/show_bug.cgi?id=83741.
--
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
Mo
Original Message
Subject: Re: [PATCH] btrfs: Fix and enhance merge_extent_mapping() to
insert best fitted extent map
From: Liu Bo
To: Qu Wenruo
Date: 2014年09月18日 12:21
On Wed, Sep 17, 2014 at 11:53:35AM +0800, Qu Wenruo wrote:
The following commit enhanced the merge_extent
Original Message
Subject: Re: [PATCH] btrfs: Fix and enhance merge_extent_mapping() to
insert best fitted extent map
From: Qu Wenruo
To:
Date: 2014年09月18日 13:36
Original Message
Subject: Re: [PATCH] btrfs: Fix and enhance merge_extent_mapping() to
insert
Run btrfs balance and subvolume create/mount/umount/delete simultaneously,
with fsstress running in background.
Signed-off-by: Eryu Guan
---
common/rc | 110 +++--
tests/btrfs/059 | 115
This patchset add new stress test cases for btrfs by running two
different btrfs operations simultaneously under fsstress to ensure
btrfs doesn't hang or oops in such situations. btrfs scrub and
btrfs check will be run after each test.
The test matrix is the combination of 6 btrfs operations:
Run btrfs balance and scrub operations simultaneously with fsstress
running in background.
Signed-off-by: Eryu Guan
---
common/rc | 9 +
tests/btrfs/060 | 114
tests/btrfs/060.out | 2 +
tests/btrfs/group | 1 +
4 fil
Run btrfs subvolume create/mount/umount/delete and btrfs scrub
operation simultaneously, with fsstress running in background.
Signed-off-by: Eryu Guan
---
tests/btrfs/065 | 115
tests/btrfs/065.out | 2 +
tests/btrfs/group | 1 +
3 f
Run btrfs subvolume create/mount/umount/delete and device replace
operation simultaneously, with fsstress running in background.
Signed-off-by: Eryu Guan
---
tests/btrfs/064 | 123
tests/btrfs/064.out | 2 +
tests/btrfs/group | 1 +
Run btrfs replace operations and scrub simultaneously with fsstress
running in background.
Signed-off-by: Eryu Guan
---
tests/btrfs/068 | 123
tests/btrfs/068.out | 2 +
tests/btrfs/group | 1 +
3 files changed, 126 insertions(+)
cr
Run btrfs balance and defrag operations simultaneously with fsstress
running in background.
Signed-off-by: Eryu Guan
---
common/rc | 20 +
tests/btrfs/061 | 116
tests/btrfs/061.out | 2 +
tests/btrfs/group | 1 +
Run btrfs subvolume create/mount/umount/delete and btrfs defrag
operations simultaneously, with fsstress running in backgound.
Signed-off-by: Eryu Guan
---
tests/btrfs/066 | 117
tests/btrfs/066.out | 2 +
tests/btrfs/group | 1 +
3
Run btrfs subvolume create/mount/umount/delete and remount with
different compress algorithms simultaneously, with fsstress running in
background.
Signed-off-by: Eryu Guan
---
tests/btrfs/067 | 116
tests/btrfs/067.out | 2 +
tests/btrfs
Run btrfs replace operations and defrag simultaneously with fsstress
running in background.
Signed-off-by: Eryu Guan
---
tests/btrfs/069 | 125
tests/btrfs/069.out | 2 +
tests/btrfs/group | 1 +
3 files changed, 128 insertions(+)
c
Run btrfs balance and remount with different compress algorithms
simultaneously, with fsstress running in background.
Signed-off-by: Eryu Guan
---
common/rc | 14 +++
tests/btrfs/062 | 114
tests/btrfs/062.out | 2 +
tests
Run btrfs balance and replace operations simultaneously with fsstress
running in background.
Signed-off-by: Eryu Guan
---
common/rc | 73 +++
tests/btrfs/063 | 122
tests/btrfs/063.out | 2 +
tests/
Run btrfs scrub and remount with different compress algorithms
simultaneously with fsstress running in background.
Signed-off-by: Eryu Guan
---
tests/btrfs/072 | 114
tests/btrfs/072.out | 2 +
tests/btrfs/group | 1 +
3 files change
Run btrfs scrub and defrag operations simultaneously with fsstress
running in background.
Signed-off-by: Eryu Guan
---
tests/btrfs/071 | 116
tests/btrfs/071.out | 2 +
tests/btrfs/group | 1 +
3 files changed, 119 insertions(+)
cre
Run btrfs replace operations and remount with different compress
algorithms simultaneously with fsstress running in background.
Signed-off-by: Eryu Guan
---
tests/btrfs/070 | 123
tests/btrfs/070.out | 2 +
tests/btrfs/group | 1 +
3
Run btrfs defrag operations and remount with different compress
algorithms simultaneously with fsstress running in background.
Signed-off-by: Eryu Guan
---
tests/btrfs/073 | 116
tests/btrfs/073.out | 2 +
tests/btrfs/group | 1 +
3
Hi Gui,
Thanks for the attempt to fix this. more below..
On 09/18/2014 11:31 AM, Gui Hecheng wrote:
*Note*: this handles the problem under umounted state,
the problem under mounted state is already fixed by Anand.
Steps to reproduce:
# mkfs.btrfs -f /dev/sda1
# btrf
I am very sorry that my commit caused the problem.
In fact some users have already find the problem and I sent the fix some
time ago.
The patch is https://patchwork.kernel.org/patch/4842201/
Hopes this helps.
Thanks,
Qu
Original Message
Subject: Re: [bug] doesn't belong to
On Thu, 2014-09-18 at 13:59 +0800, Anand Jain wrote:
>
> Hi Gui,
>
> Thanks for the attempt to fix this. more below..
>
> On 09/18/2014 11:31 AM, Gui Hecheng wrote:
> > *Note*: this handles the problem under umounted state,
> > the problem under mounted state is already fixed by Anand.
>
63 matches
Mail list logo
