On 18/6/2014 5:11 πμ, Jens Axboe wrote:
On 2014-06-17 14:35, Konstantinos Skarlatos wrote:
Hi all,
with 3.16-rc1 rsync stops writing to my btrfs filesystem and stays at a
D+ state.
git bisect showed that the problematic commit is:
762380ad9322951cea4ce9d24864265f9c66a916 is the first bad commi
Hello Josef,
The lastest Qgroup code still break this test sometimes.
Ps: this test seems not merging into xfstests.
On 05/09/2014 02:02 PM, Wang Shilong wrote:
Test flow is to run fsstress after triggering quota rescan.
the ruler is simple, we just remove all files and directories,
sync files
On Mon, Jun 16, 2014 at 11:10:15AM -0400, Cristian Rodríguez wrote:
> El 13/06/14 10:41, Werner Fink escribió:
> > That is: set NOATIME, NOCOW, and NOCOMP for the journal directory
> >
> > ---
> > src/journal/journald-server.c | 29 +++--
> > 1 file changed, 27 insertion
Hi Filipe,
I finally got to debug this deeper. As it turns out, this happens only
if both "nospace_cache" and "clear_cache" are specified. You need to
unmount and mount again to cause this. After mounting, due to
"clear_cache", all the block-groups are marked as BTRFS_DC_CLEAR, and
then cache_save_
On 17/6/2014 9:27 μμ, Marc MERLIN wrote:
On Tue, Jun 17, 2014 at 07:59:57AM -0700, Marc MERLIN wrote:
It is also ok to answer "Any FS created or used before kernel 3.x can be
corrupted due to bugs we fixed in 3.y, thank you for your report but it's
not a good use of our time to investigate this"
On Mon, Jun 16, 2014 at 03:09:53PM +0800, Wang Shilong wrote:
> 1) Is that expected/normal? It looks kind of spamming/useless to me?
> 2) If it's useful, what's the use I'm not getting?
> >>>Addressed a issue that subvolumes reappear after deletetion if poweroff
> >>>happen.
> >>>
> >>>http
On Wed, Jun 18, 2014 at 04:19:32PM +0200, David Sterba wrote:
> On Mon, Jun 16, 2014 at 03:09:53PM +0800, Wang Shilong wrote:
> > 1) Is that expected/normal? It looks kind of spamming/useless to me?
> > 2) If it's useful, what's the use I'm not getting?
> > >>>Addressed a issue that subvolu
On Wed, Jun 18, 2014 at 03:20:30PM +0900, Satoru Takeuchi wrote:
> Hi Adam,
>
> (2014/06/14 6:18), Adam Buchbinder wrote:
> > When running with UndefinedBehaviorSanitizer, the tests produce the
> > following
> > error:
> >
> >radix-tree.c:836:30: runtime error: shift exponent 184467440737095
On 06/18/2014 01:36 AM, Wang Shilong wrote:
Hello Josef,
The lastest Qgroup code still break this test sometimes.
Ps: this test seems not merging into xfstests.
Yeah Chris said something about this yesterday, I'll try and get a vm up
and running on my laptop soon and take a look at this.
On 06/17/2014 11:55 AM, Marc MERLIN wrote:
On Tue, Jun 17, 2014 at 11:29:57AM -0700, Josef Bacik wrote:
I'm sure that filesystem is damaged in some way, but the kernel of course
should not crash.
I don't have this mail client setup right to send patches, can you just
go into relocation.c in
On Thu, Jun 12, 2014 at 09:39:14AM -0500, Eric Sandeen wrote:
> > So what if the mount options are generated from btrfs-mount.txt but
> > installed under btrfs.5.gz name? If there are more section 5 manpages we
> > can make it more generic but for now hardcoding btrfs-mount.* ->
> > btrfs.5. sounds
On Fri, Jun 13, 2014 at 10:55:57AM +0800, Qu Wenruo wrote:
> v3:
>Don't reparse size twice
>Better u64 overflow check
Thanks. I've tested the limits, overflow checks and negative numbers,
works fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a
On 2014-06-18 00:21, Konstantinos Skarlatos wrote:
On 18/6/2014 5:11 πμ, Jens Axboe wrote:
On 2014-06-17 14:35, Konstantinos Skarlatos wrote:
Hi all,
with 3.16-rc1 rsync stops writing to my btrfs filesystem and stays at a
D+ state.
git bisect showed that the problematic commit is:
762380ad932
On 6/18/14, 10:29 AM, David Sterba wrote:
> On Thu, Jun 12, 2014 at 09:39:14AM -0500, Eric Sandeen wrote:
>>> So what if the mount options are generated from btrfs-mount.txt but
>>> installed under btrfs.5.gz name? If there are more section 5 manpages we
>>> can make it more generic but for now har
On Wed, Jun 04, 2014 at 04:43:11PM -0400, Jeff Mahoney wrote:
> --- a/utils.c
> +++ b/utils.c
> @@ -987,6 +987,63 @@ static int blk_file_in_dev_list(struct b
> }
>
> /*
> + * Resolve a pathname to a device mapper node to /dev/mapper/
> + * Returns NULL on invalid input or malloc failure; Other
When things go wrong for lzo-compressed btrfs, feeding lzo1x_decompress_safe()
with corrupt data during restore can lead to crashes. Reduce the risk by adding
a check on the input length.
Signed-off-by: Vincent Stehlé
---
Hi,
This patch actually allowed me to finish a btrfs restore of a damaged
BugLink: http://bugs.launchpad.net/bugs/1324953
Hello,
Please consider including upstream commit c41570c9 in the next v3.13.y release.
It was included upstream as of v3.14-rc2. It has been tested and confirmed to
resolve http://bugs.launchpad.net/bugs/1324953 .
commit c41570c9d29764f797fa35
Hello,
Please consider including upstream commit b7a77235 in the next v3.13.y release.
It was included upstream as of v3.15-rc5. It has been tested and confirmed to
resolve http://bugs.launchpad.net/bugs/1319457 .
commit b7a7723513dc89f83d6df13206df55d4dc26e825
Author: Sander Eikelenboom
Dat
From: Sander Eikelenboom
BugLink: http://bugs.launchpad.net/bugs/1319457
This (widely used) construction:
if(printk_ratelimit())
dev_dbg()
Causes the ratelimiting to spam the kernel log with the "callbacks suppressed"
message below, even while the dev_dbg it is supposed to rate limit w
Hi,
I created btrfs directly to disk using such a scheme (no partitions):
dd if=/dev/zero of=/dev/sda bs=4096
mkfs.btrfs -L dev_sda /dev/sda
mount /dev/sda /mnt
cd /mnt
btrfs subvolume create __active
btrfs subvolume create __active/rootvol
btrfs subvolume create __active/usr
btrfs subvolume crea
On Jun 18, 2014, at 1:29 PM, Daniel Cegiełka wrote:
> Hi,
> I created btrfs directly to disk using such a scheme (no partitions):
>
> dd if=/dev/zero of=/dev/sda bs=4096
> mkfs.btrfs -L dev_sda /dev/sda
> mount /dev/sda /mnt
>
> cd /mnt
> btrfs subvolume create __active
> btrfs subvolume creat
First thanks for your answer and patch. While they didn't help, I'm happy to
try another one or two if you'd like before I wipe the FS to recover.
On Wed, Jun 18, 2014 at 08:26:46AM -0700, Josef Bacik wrote:
> >2) is your guess that the BUG_ON I'm getting shouldn't be triggered
> >and your propose
Hi,
I've been seeing very reproducible soft lockups with 3.16-rc1 similar
to what is reported here:
http://marc.info/?l=linux-btrfs&m=140290088532203&w=2 , along with the
occasional hard lockup, making it impossible to complete a parallel
build on a btrfs filesystem for the package I work on. Thi
info at http://vger.kernel.org/majordomo-info.html
Hi David,
I think you forgot to apply the patch that adds
Documentation/btrfs-mount.5.txt before you tagged
integration-20140618, man5 (and consequently Documentation) can't be
made without it, causing a failed build.
make: *** No rule to
On 6/18/14, Daniel Cegiełka wrote:
> I created btrfs directly to disk using such a scheme (no partitions):
> cd /mnt
> btrfs subvolume create __active
> btrfs subvolume create __active/rootvol
> Everything works fine. Is such a solution is recommended? In my
> opinion, the creation of the partitio
Konstantinos Skarlatos posted on Wed, 18 Jun 2014 16:23:04 +0300 as
excerpted:
> I guess that btrfs developers have put these BUG_ONs so that they get
> reports from users when btrfs gets in these unexpected situations. But
> if most of these reports are ignored or not resolved, then maybe there
>
On 06/18/2014 04:57 PM, Marc Dionne wrote:
Hi,
I've been seeing very reproducible soft lockups with 3.16-rc1 similar
to what is reported here:
http://marc.info/?l=linux-btrfs&m=140290088532203&w=2 , along with the
occasional hard lockup, making it impossible to complete a parallel
build on a btr
On 06/18/2014 03:17 PM, Waiman Long wrote:
On 06/18/2014 04:57 PM, Marc Dionne wrote:
Hi,
I've been seeing very reproducible soft lockups with 3.16-rc1 similar
to what is reported here:
https://urldefense.proofpoint.com/v1/url?u=http://marc.info/?l%3Dlinux-btrfs%26m%3D140290088532203%26w%3D2&
On 06/18/2014 06:27 PM, Josef Bacik wrote:
On 06/18/2014 03:17 PM, Waiman Long wrote:
On 06/18/2014 04:57 PM, Marc Dionne wrote:
Hi,
I've been seeing very reproducible soft lockups with 3.16-rc1 similar
to what is reported here:
https://urldefense.proofpoint.com/v1/url?u=http://marc.info/?l%
On Wed, Jun 18, 2014 at 09:59:50PM +0100, WorMzy Tykashi wrote:
> I think you forgot to apply the patch that adds
> Documentation/btrfs-mount.5.txt before you tagged
> integration-20140618, man5 (and consequently Documentation) can't be
> made without it, causing a failed bui
On 06/18/2014 03:47 PM, Waiman Long wrote:
On 06/18/2014 06:27 PM, Josef Bacik wrote:
On 06/18/2014 03:17 PM, Waiman Long wrote:
On 06/18/2014 04:57 PM, Marc Dionne wrote:
Hi,
I've been seeing very reproducible soft lockups with 3.16-rc1 similar
to what is reported here:
https://urldefens
On 06/18/2014 07:10 PM, Josef Bacik wrote:
On 06/18/2014 03:47 PM, Waiman Long wrote:
On 06/18/2014 06:27 PM, Josef Bacik wrote:
On 06/18/2014 03:17 PM, Waiman Long wrote:
On 06/18/2014 04:57 PM, Marc Dionne wrote:
Hi,
I've been seeing very reproducible soft lockups with 3.16-rc1 similar
On 06/18/2014 07:19 PM, Waiman Long wrote:
> On 06/18/2014 07:10 PM, Josef Bacik wrote:
>>
>>
>> On 06/18/2014 03:47 PM, Waiman Long wrote:
>>> On 06/18/2014 06:27 PM, Josef Bacik wrote:
On 06/18/2014 03:17 PM, Waiman Long wrote:
> On 06/18/2014 04:57 PM, Marc Dionne wrote:
>
On 06/18/2014 07:27 PM, Chris Mason wrote:
On 06/18/2014 07:19 PM, Waiman Long wrote:
On 06/18/2014 07:10 PM, Josef Bacik wrote:
On 06/18/2014 03:47 PM, Waiman Long wrote:
On 06/18/2014 06:27 PM, Josef Bacik wrote:
On 06/18/2014 03:17 PM, Waiman Long wrote:
On 06/18/2014 04:57 PM, Marc Dio
On 06/18/2014 07:30 PM, Waiman Long wrote:
> On 06/18/2014 07:27 PM, Chris Mason wrote:
>> On 06/18/2014 07:19 PM, Waiman Long wrote:
>>> On 06/18/2014 07:10 PM, Josef Bacik wrote:
On 06/18/2014 03:47 PM, Waiman Long wrote:
> On 06/18/2014 06:27 PM, Josef Bacik wrote:
>>
>> On
On Wed, Jun 18, 2014 at 7:53 PM, Chris Mason wrote:
> On 06/18/2014 07:30 PM, Waiman Long wrote:
>> On 06/18/2014 07:27 PM, Chris Mason wrote:
>>> On 06/18/2014 07:19 PM, Waiman Long wrote:
On 06/18/2014 07:10 PM, Josef Bacik wrote:
>
> On 06/18/2014 03:47 PM, Waiman Long wrote:
>
On Wed, 18 Jun 2014 21:29:39 Daniel Cegiełka wrote:
> Everything works fine. Is such a solution is recommended? In my
> opinion, the creation of the partitions seems to be completely
> unnecessary if you can use btrfs.
For boot disks I use the traditional partitioning system. So far I don't run
On 06/18/2014 08:03 PM, Marc Dionne wrote:
On Wed, Jun 18, 2014 at 7:53 PM, Chris Mason wrote:
On 06/18/2014 07:30 PM, Waiman Long wrote:
On 06/18/2014 07:27 PM, Chris Mason wrote:
On 06/18/2014 07:19 PM, Waiman Long wrote:
On 06/18/2014 07:10 PM, Josef Bacik wrote:
On 06/18/2014 03:47 PM,
On Wed, Jun 18, 2014 at 8:08 PM, Waiman Long wrote:
> On 06/18/2014 08:03 PM, Marc Dionne wrote:
>>
>> On Wed, Jun 18, 2014 at 7:53 PM, Chris Mason wrote:
>>>
>>> On 06/18/2014 07:30 PM, Waiman Long wrote:
On 06/18/2014 07:27 PM, Chris Mason wrote:
>
> On 06/18/2014 07:19 PM, Wa
On Wed, Jun 18, 2014 at 04:36:22PM +0800, Wang Shilong wrote:
> Hello Josef,
>
> The lastest Qgroup code still break this test sometimes.
>
> Ps: this test seems not merging into xfstests.
Then repost it to fste...@vger.kernel.org. Sometimes patches get
missed...
Cheers,
Dave.
--
Dave Chinne
A lot of good comments on this topic already. I would just add that on
large (TB) drives, not partitioning can result in some pretty slow mount
and umount times (even applies to mounting subvolumes). That is one of
the frustrating side effects I have noticed with a non-partitioned 4TB
drive o
Hi David, Adam,
(2014/06/18 23:43), David Sterba wrote:
On Wed, Jun 18, 2014 at 03:20:30PM +0900, Satoru Takeuchi wrote:
Hi Adam,
(2014/06/14 6:18), Adam Buchbinder wrote:
When running with UndefinedBehaviorSanitizer, the tests produce the following
error:
radix-tree.c:836:30: runtime er
On Mon, Jun 16, 2014 at 12:13:07AM +0200, Lennart Poettering wrote:
> On Sat, 14.06.14 09:52, Goffredo Baroncelli (kreij...@libero.it) wrote:
>
> > > Which effectively means that by the time the 8 MiB is filled, each 4 KiB
> > > block has been rewritten to a new location and is now an extent unto
Steps to reproduce:
# mkfs.btrfs -f /dev/sda9
# mount /dev/sda9 /mnt
# dd if=/dev/zero of=/mnt/data bs=1M count=1
# btrfs restore -r /dev/sda9 -r 2 -o /tmp
If users don't input a valid fs/file root objectid, btrfs restore still
continue and don't restore anything, this is unfriendly, we could
Steps to reproduce:
# mkfs.btrfs -f /dev/sda9
# btrfs restore -f 1 -o /tmp /dev/sda9
# echo $?
Fix to return 1 in this failure path.
Signed-off-by: Wang Shilong
---
cmds-restore.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmds-restore.c b/cmds-restore.c
index 934755a..48c46ff 10064
Add some missing options, also improve some confusing
expressions.
Signed-off-by: Wang Shilong
---
Documentation/btrfs-restore.txt | 26 ++
cmds-restore.c | 7 ---
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/Documentation/btrfs-r
Previously if restore could not read users specified fs root, it would
output following message:
Error reading root
With this patch, it will output message like:
Fail to read root 1000: No such file or directory
Signed-off-byr Wang Shilong
---
cmds-restore.c | 3 ++-
1 file changed, 2 inser
Signed-off-by: Wang Shilong
---
cmds-check.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/cmds-check.c b/cmds-check.c
index c56da2a..26baab0 100644
--- a/cmds-check.c
+++ b/cmds-check.c
@@ -2049,13 +2049,10 @@ skip_walking:
static int fs_root_objectid(u64 object
These two options are used for same purpose, but they are exclusive with
each other. Make it clear to common users.
Signed-off-by: Wang Shilong
---
cmds-restore.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/cmds-restore.c b/cmds-restore.c
index 8267ab6..3a29ed6 100644
--- a/cmds-res
The value of variable leaf in while loop don't have to be set
for every round. Just move it outside.
Signed-off-by: Gui Hecheng
---
btrfs-image.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/btrfs-image.c b/btrfs-image.c
index cf1fe2d..db5d193 100644
--- a/btrfs-imag
The btrfs-image support multiple devices with -m specified.
Signed-off-by: Gui Hecheng
---
Documentation/btrfs-image.txt | 3 +++
btrfs-image.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/Documentation/btrfs-image.txt b/Documentation/btrfs-image.txt
index 7ee820c..15519
For btrfs-image,
dumpmay not come with option '-o'
-r may not come with option '-c', '-s', '-w', dev_cnt != 1
-m may not come with dev_cnt < 2
All of the above should be regarded as invalid combinations,
and the usage will show up.
Signed-off-by: Gui Hecheng
When btrfs-image failed to create an image, the invalid output file
had better be deleted to prevent being used mistakenly in the future.
Signed-off-by: Gui Hecheng
---
btrfs-image.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/btrfs-image.c b/btrfs-image.c
index
On Wed, 2014-06-18 at 14:32 -0400, Joseph Salisbury wrote:
> From: Sander Eikelenboom
>
> BugLink: http://bugs.launchpad.net/bugs/1319457
>
> This (widely used) construction:
>
> if(printk_ratelimit())
> dev_dbg()
>
> Causes the ratelimiting to spam the kernel log with the "callbacks sup
On Wed, Jun 18, 2014 at 8:41 PM, Marc Dionne wrote:
> On Wed, Jun 18, 2014 at 8:08 PM, Waiman Long wrote:
>> On 06/18/2014 08:03 PM, Marc Dionne wrote:
>>>
>>> On Wed, Jun 18, 2014 at 7:53 PM, Chris Mason wrote:
On 06/18/2014 07:30 PM, Waiman Long wrote:
>
> On 06/18/2014 07:27
On 06/18/2014 10:03 PM, Marc Dionne wrote:
> On Wed, Jun 18, 2014 at 8:41 PM, Marc Dionne wrote:
>> On Wed, Jun 18, 2014 at 8:08 PM, Waiman Long wrote:
>>> On 06/18/2014 08:03 PM, Marc Dionne wrote:
>
> And for an additional data point, just removing those
> CONFIG_DEBUG_LOCK_ALLOC ifdefs looks
This is a random bugfix patchset. patch 0001, 0005, 0006, 0007 is new patch,
patch 0002 is the third version of broken free space cache fix patch,
patch 0003, 0004 is old ones which are not merged.
We can pull this patchset from the URL
https://github.com/miaoxie/linux-btrfs.git for-Chris
Than
Signed-off-by: Miao Xie
---
fs/btrfs/volumes.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 19c298a..31f9036 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -5399,12 +5399,6 @@ static void btrfs_end_bio(struc
This patch makes the free space cache write out functions more readable,
and beisdes that, it also reduces the stack space that the function --
__btrfs_write_out_cache uses from 194bytes to 144bytes.
Signed-off-by: Miao Xie
---
fs/btrfs/free-space-cache.c | 159 ++
From: Qu Wenruo
When run scrub with balance, sometimes -ENOENT will be returned, since
in scrub_enumerate_chunks() will search dev_extent in *COMMIT_ROOT*, but
btrfs_lookup_block_group() will search block group in *MEMORY*, so if a
chunk is removed but not committed, -ENOENT will be returned.
Ho
The deadlock happened when we mount degraded filesystem, the reproduced
steps are following:
# mkfs.btrfs -f -m raid1 -d raid1
# echo 1 > /sys/block/`basename `/device/delete
# mount -o degraded
The reason was that the counter -- bi_remaining was wrong. If the missing
or unwriteable device
The original bio might be submitted, so we shoud increase bi_remaining to
account for it when we deal with the error that the device is missing or
is not writeable, or we would skip the endio handle.
Signed-off-by: Miao Xie
---
fs/btrfs/volumes.c | 22 +++---
1 file changed, 15 i
When we mounted the filesystem after the crash, we got the following
message:
BTRFS error (device xxx): block group has wrong amount of free space
BTRFS error (device xxx): failed to load free space cache for block group xxx
It is because we didn't update the metadata of the allocated spa
From: Wang Shilong
While running balance, scrub, fsstress concurrently we hit the
following kernel crash:
[56561.448845] BTRFS info (device sde): relocating block group 11005853696
flags 132
[56561.524077] BUG: unable to handle kernel NULL pointer dereference at
0078
[56561.524237]
Test flow is to run fsstress after triggering quota rescan.
the ruler is simple, we just remove all files and directories,
sync filesystem and see if qgroup's ref and excl are nodesize.
Signed-off-by: Wang Shilong
Reviewed-by: Josef Bacik
---
v2->v3: addressed comments from josef:
- remo
On 06/18/2014 10:11 PM, Chris Mason wrote:
On 06/18/2014 10:03 PM, Marc Dionne wrote:
On Wed, Jun 18, 2014 at 8:41 PM, Marc Dionne wrote:
On Wed, Jun 18, 2014 at 8:08 PM, Waiman Long wrote:
On 06/18/2014 08:03 PM, Marc Dionne wrote:
And for an additional data point, just removing those
CONF
Btrfs has global block reservation, so even mkfs.btrfs can execute
without problem, there is still a possibility that the filesystem can't
be mounted.
For example when mkfs.btrfs on a 8M file on x86_64 platform, kernel will
refuse to mount due to ENOSPC, since system block group takes 4M and
mixed
Btrfs has global block reservation, so even mkfs.btrfs can execute
without problem, there is still a possibility that the filesystem can't
be mounted.
For example when mkfs.btrfs on a 8M file on x86_64 platform, kernel will
refuse to mount due to ENOSPC, since system block group takes 4M and
mixed
On Wed, 18 Jun 2014 18:01:44 George Mitchell wrote:
> A lot of good comments on this topic already. I would just add that on
> large (TB) drives, not partitioning can result in some pretty slow mount
> and umount times (even applies to mounting subvolumes).
If you mount a subvol then the kernel
69 matches
Mail list logo
