Original Message
Subject: Re: [PATCH 2/5] btrfs: correct a message on setting nodatacow
From: Satoru Takeuchi
To: Qu Wenruo , linux-btrfs@vger.kernel.org
Date: 2014年09月19日 14:45
Hi Qu,
Thank you for your comment.
(2014/09/19 11:03), Qu Wenruo wrote:
Original Me
(2014/09/18 17:55), 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.
>
> [BUG]
> When exist
From: Naohiro Aota
In the current implementation, compression property == "" has
the two different meanings: one is with BTRFS_INODE_NOCOMPRESS,
and the other is without this flag.
So, even if the two files a and b have the same compression
property, "", and the same contents, one file seems to
From: Naohiro Aota
This new compression property, "off", to disable compression of
the file at all.
Signed-off-by: Naohiro Aota
Signed-off-by: Satoru Takeuchi
---
fs/btrfs/props.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/fs/btrfs/props.c b/fs/btrfs/props.c
index bf00
From: Naohiro Aota
Export __btrfs_set_prop() to be able to call it
with running transaction.
Signed-off-by: Naohiro Aota
Signed-off-by: Satoru Takeuchi
---
fs/btrfs/props.c | 2 +-
fs/btrfs/props.h | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/props.c b/fs
This patch series moves the generic RCU string library used internally by BTRFS
to be accessible by anyone. It provides printk_in_rcu and
printk_ratelimited_in_rcu to print these strings. In order to avoid a weird
inconsistency between the two, the first patch fixes printk_ratelimited so it
passes
The RCU-friendy string API used internally by BTRFS is generic enough for
common use. This doesn't add any new functionality, but instead just moves the
code and documents the existing API.
Signed-off-by: Omar Sandoval
---
fs/btrfs/check-integrity.c | 6 +--
fs/btrfs/dev-replace.c | 19
printk returns an integer; there's no reason for printk_ratelimited to swallow
it.
Signed-off-by: Omar Sandoval
---
include/linux/printk.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index d78125f..67534bc 100644
--- a/in
From: Naohiro Aota
Fix the following two problems in compression related ioctl code.
a) Updating compression flags and updating inode attribute
in two separated transaction. So, if something bad happens
after the former, and before the latter, file system
would become inconsiste
Hi,
my btrfs partition got corrupted. With some trouble I got most of the
valuable data out of it using `btrfs restore -i` (it crashed a few
times, but on the fourth or fifth run it reached the stuff I wanted to
recover). As far as I can tell, the file system broke during normal
operations wi
Looks good to me Chris. Thank you.
Reviewed-by: Anand Jain
On 09/18/2014 11:00 PM, Chris Mason wrote:
Johannes and Sam, could you please confirm this patch fixes your mount
regression for now? Anand, please make sure I kept the generation check
properly.
This reverts commit b96de000bc
Hi,
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dropping
caches, whereas on other machines using ext4 this takes about 13s. My
mail client (
Le vendredi 19 septembre 2014, 13:18:34 Rob Spanton a écrit :
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs.
Weeelll I have the same over-complicated kind of setup, and an Arch Linux
BTRFS system which used to
On 2014-09-19 08:18, Rob Spanton wrote:
Hi,
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dropping
caches, whereas on other machines using ex
On 2014-09-19 08:25, Swâmi Petaramesh wrote:
Le vendredi 19 septembre 2014, 13:18:34 Rob Spanton a écrit :
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs.
Weeelll I have the same over-complicated kind of setup,
On 2014-09-19 08:49, Austin S Hemmelgarn wrote:
On 2014-09-19 08:18, Rob Spanton wrote:
Hi,
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dr
On 09/18/2014 09:45 PM, Qu Wenruo wrote:
> Hi Chris,
>
>
> I'm sorry that the commit 'btrfs: Fix and enhance merge_extent_mapping()
> to insert best fitted extent map'
> has a V2 patch, so the one in tree is not up-to-data.
>
> Although the v2 change is quite small and it's relevantly dependent,
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs. A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other
On 18/09/14 16:00, Chris Mason wrote:
Johannes and Sam, could you please confirm this patch fixes your mount
regression for now? Anand, please make sure I kept the generation check
properly.
I've just tested this patch on top of 3.17-rc5 and it fixes the issue
for me.
Thanks!
Sam
--
Sam
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs. A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other
On 09/19/2014 09:47 AM, Sam Thursfield wrote:
> On 18/09/14 16:00, Chris Mason wrote:
>>
>> Johannes and Sam, could you please confirm this patch fixes your mount
>> regression for now? Anand, please make sure I kept the generation check
>> properly.
>
> I've just tested this patch on top of 3.17
When balance panics it tends to panic in the
BUG_ON(!upper->checked);
test, because it means it couldn't build the backref tree properly. This is
annoying to users and frankly a recoverable error, nothing in this function is
actually fatal since it is just an in-memory building of the backrefs f
On 2014-09-19 09:51, Holger Hoffstätte wrote:
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 second
On 09/02/2014 11:25 PM, Liu Bo wrote:
From: Liu Bo
btrfs/012 is a case to verify btrfs-convert feature, it converts an ext4 to
btrfs firstly and do something, then rolls back to ext4.
So at last we have a ext4 on the scratch device, but setting _require_scratch
will force a btrfsck on a ext4 f
On 09/19/2014 08:18 AM, Rob Spanton wrote:
Hi,
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dropping
caches, whereas on other machines using
On Fri, Sep 19, 2014 at 02:01:28AM -0700, Omar Sandoval wrote:
> This patch series moves the generic RCU string library used internally by
> BTRFS
> to be accessible by anyone. It provides printk_in_rcu and
> printk_ratelimited_in_rcu to print these strings. In order to avoid a weird
> inconsisten
On 09/19/2014 11:45 AM, Paul E. McKenney wrote:
> On Fri, Sep 19, 2014 at 02:01:28AM -0700, Omar Sandoval wrote:
>> This patch series moves the generic RCU string library used internally by
>> BTRFS
>> to be accessible by anyone. It provides printk_in_rcu and
>> printk_ratelimited_in_rcu to prin
On Fri, Sep 19, 2014 at 11:47:53AM -0400, Chris Mason wrote:
>
>
> On 09/19/2014 11:45 AM, Paul E. McKenney wrote:
> > On Fri, Sep 19, 2014 at 02:01:28AM -0700, Omar Sandoval wrote:
> >> This patch series moves the generic RCU string library used internally by
> >> BTRFS
> >> to be accessible by
On 09/19/2014 12:05 PM, Paul E. McKenney wrote:
> On Fri, Sep 19, 2014 at 11:47:53AM -0400, Chris Mason wrote:
>>
>>
>> On 09/19/2014 11:45 AM, Paul E. McKenney wrote:
>>> On Fri, Sep 19, 2014 at 02:01:28AM -0700, Omar Sandoval wrote:
This patch series moves the generic RCU string library used
On Fri, 19 Sep 2014 10:53:03 -0400, Austin S Hemmelgarn wrote:
> I find that kind of funny, because regardless of filesystem, stat() is
> one of the *slowest* syscalls on almost every *nix system in existence.
Sure. I didn't mean to imply that stat() in its various incarnations is
fast by itself
Hi,
Thanks for the response everyone.
I wrote:
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs. A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other machine
Possibly btrfs-select-super can do some of the things I was doing the hard way.
It's possible to select a super to overwrite other supers, even if they're
"good" ones. Whereas btrfs rescue super-recover won't do that, and neither will
btrfsck, hence why I corrupted the one I didn't want first. T
On Sep 19, 2014, at 2:58 AM, Jakob Breier wrote:
> Unfortunately I don't have much to work with. Can you help me with extracting
> enough information to create a useful bugreport?
What storage device(s)?
Include results from
# btrfs check
And also a note whether you get different results with
On Fri, 19 Sep 2014 02:01:29 -0700
Omar Sandoval wrote:
> printk returns an integer; there's no reason for printk_ratelimited to swallow
> it.
>
> Signed-off-by: Omar Sandoval
> ---
> include/linux/printk.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/li
On 2014-09-19 13:07, Chris Murphy wrote:
Possibly btrfs-select-super can do some of the things I was doing the hard way. It's
possible to select a super to overwrite other supers, even if they're "good"
ones. Whereas btrfs rescue super-recover won't do that, and neither will btrfsck, hence
why
On 09/19/2014 11:51 AM, Rob Spanton wrote:
Hi,
Thanks for the response everyone.
I wrote:
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dro
On Fri, Sep 19, 2014 at 01:51:22PM +, Holger Hoffstätte wrote:
>
> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
>
> > I have a particularly uncomplicated setup (a desktop PC with a hard
> > disk) and I'm seeing particularly slow performance from btrfs. A `git
> > status` in the lin
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn wrote:
[ 30.920536] BTRFS: bad tree block start 0 130402254848
[ 30.924018] BTRFS: bad tree block start 0 130402254848
[ 30.926234] BTRFS: failed to read log tree
[ 30.953055] BTRFS: open_ctree failed
I'm still confused. Btrfs knows this
With the advanced features of btrfs, it would be an additional simple task to
make different platters run in parallel.
In this case, say a disk has three platters, and so three seek heads as well.
If we can identify that much, and what offsets they are at, it then becomes a
trivial matter to p
On Fri, 2014-09-19 at 13:21 -0400, Steven Rostedt wrote:
> On Fri, 19 Sep 2014 02:01:29 -0700
> Omar Sandoval wrote:
>
> > printk returns an integer; there's no reason for printk_ratelimited to
> > swallow
> > it.
Except for the lack of usefulness of the return value itself.
See: https://lkml.o
On 2014-09-19 13:54, Chris Murphy wrote:
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn wrote:
[ 30.920536] BTRFS: bad tree block start 0 130402254848
[ 30.924018] BTRFS: bad tree block start 0 130402254848
[ 30.926234] BTRFS: failed to read log tree
[ 30.953055] BTRFS: open_ctree fa
On 2014-09-19 14:10, Jeb Thomson wrote:
With the advanced features of btrfs, it would be an additional simple task to
make different platters run in parallel.
In this case, say a disk has three platters, and so three seek heads as well.
If we can identify that much, and what offsets they are a
Marc Merlin sent me a broken fs image months ago where it would blow up in the
upper->checked BUG_ON() in build_backref_tree. This is because we had a
scenario like this
block a -- level 4 (not shared)
|
block b -- level 3 (reloc block, shared)
|
block c -- level 2 (not shared)
|
block d
Hi Linus,
We have two more fixes for pulling:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
I've got a revert to fix a regression with btrfs device registration,
and Filipe has part two of his fsync fix from last week.
Chris Mason (1) commits (+6/-7):
Revert
Hey guys...
I was just crawling through the wiki and this list's archive to find
answers about some questions.
Actually many of them matching those which Christoph has asked here
some time ago, though it seems no answers came up at all.
Isn't it possible to answer them, at least one by one? I'd b
On 09/19/2014 11:10 AM, Jeb Thomson wrote:
With the advanced features of btrfs, it would be an additional simple task to
make different platters run in parallel.
In this case, say a disk has three platters, and so three seek heads as well.
If we can identify that much, and what offsets they ar
Hey Fellow Developers,
I am new to working on the Linux Kernel and am interested in helping out with
btrfs file system and it's respective
user space tools. If anyone either has some work or would like to mentor me
with the code base that would be greatly
appreciated. In addition I hope to do th
Rob Spanton posted on Fri, 19 Sep 2014 17:51:09 +0100 as excerpted:
> The evolution problem has been improved: the sqlite db that it was using
> had over 18000 fragments, so I got evolution to recreate that file with
> nocow set. It now takes "only" 30s to load my mail rather than 80s,
> which is
48 matches
Mail list logo
