Balance recovery is called when RW mounting or remounting from
RO to RW, it is called to finish roots merging.
When doing balance recovery, relocation root's corresponding
fs root(whose root refs is 0) might be destroyed by cleaner
thread, this will make btrfs fail to mount.
Fix this problem by h
If the malloc above fails, the btrfs-image will exit directly
without any error messages.
Now just return the ENOMEM errno and let the caller prompt the
error message.
Signed-off-by: Gui Hecheng
---
btrfs-image.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/btrfs-image.c
Don't bother free the buffer if the malloc failed.
Signed-off-by: Gui Hecheng
---
btrfs-image.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/btrfs-image.c b/btrfs-image.c
index 7131001..2d482c3 100644
--- a/btrfs-image.c
+++ b/btrfs-image.c
@@ -1631,7 +1631,7 @@ static voi
The btrfs-image requires at least 2 args to run,
one for the source dev/file, the other for the target dev/file.
Signed-off-by: Gui Hecheng
---
btrfs-image.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/btrfs-image.c b/btrfs-image.c
index e0aabfd..b13f236 100644
--- a/btrfs-image.c
+++
Steps to reproduce:
# mkfs.btrfs -f
# btrfs-image
# btrfs-image -r -o
# btrfs check
btrfs check output:
: read block failed check_tree_block
: Couldn't read tree root
: Couldn't open file system
The btrfs-image should not mess with the
Handle the malloc failure for dump_worker in the same way as
the restore worker.
Signed-off-by: Gui Hecheng
---
btrfs-image.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/btrfs-image.c b/btrfs-image.c
index c90bca8..7131001 100644
--- a/btrfs-image.c
++
Signed-off-by: Gui Hecheng
---
btrfs-image.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/btrfs-image.c b/btrfs-image.c
index b13f236..ed0b6ec 100644
--- a/btrfs-image.c
+++ b/btrfs-image.c
@@ -1163,7 +1163,7 @@ static int copy_from_extent_tree(struct meta
Original Message
Subject: [PATCH, RFC] btrfs: refactor open_ctree()
From: Eric Sandeen
To: linux-btrfs
Date: 2014年06月26日 07:55
First off: total RFC, don't merge this; it builds, but
is totally untested.
open_ctree() is almost 1000 lines long. I've started trying
to refactor
First off: total RFC, don't merge this; it builds, but
is totally untested.
open_ctree() is almost 1000 lines long. I've started trying
to refactor it, primarily into helper functions, and also
simplifying (?) things a bit at the beginning by removing the
ret = func(); if (ret) { err = ret; goto
i'm experiencing what I think are issues with btrfs and suspend/resume,
after a resume, I can no longer start any virtual machines in virtualbox
also, if I attempt a df command, it will just hang. Both of these events
work fine
prior to suspend resume as well as before I migrated to btrfs.
Things
On 25/6/2014 5:41 μμ, Christoph Anton Mitterer wrote:
On Wed, 2014-06-25 at 08:47 +0100, Hugo Mills wrote:
This has variously been possible and not over the last few years. I
think it's finally come down on the side of "not",
I think that would really be a loss... :(
The question is,
On 06/25/2014 12:40 PM, Marc MERLIN wrote:
On Fri, Jun 20, 2014 at 08:40:49AM -0700, Josef Bacik wrote:
On 06/19/2014 05:53 PM, Marc MERLIN wrote:
On Thu, Jun 19, 2014 at 03:50:16PM -0700, Josef Bacik wrote:
Ok same drill as before, reset and apply this, hopefully no panic this
time
diff --g
This is a regression from my patch a26e8c9f75b0bfd89e8f110737b136eb5994, we
need to only unlock the block if we were the one who locked it. Otherwise this
will trip BUG_ON()'s in locking.c Thanks,
cc: sta...@vger.kernel.org
Signed-off-by: Josef Bacik
---
fs/btrfs/disk-io.c | 3 ++-
1 file
This change is based on the corresponding recent change for ext4:
ext4: atomically set inode->i_flags in ext4_set_inode_flags()
That has the following commit message that applies to btrfs as well:
"Use cmpxchg() to atomically set i_flags instead of clearing out the
S_IMMUTABLE, S_APPEND,
On Jun 25, 2014, at 1:32 PM, Mike Hartman wrote:
>> I don't know all states of this file system, and copies you have. Right now
>> the earliest copy is obviously broken, and the latest copy is probably more
>> broken because at the least its csum tree has been blown away meaning
>> there's no
On Mon, Jun 23, 2014 at 05:04:42PM +0200, David Sterba wrote:
> On Mon, Jun 23, 2014 at 04:23:48AM +0200, Nils Steinger wrote:
> > + rmdir -p --ignore-fail-on-non-empty $(DESTDIR)$(man8dir)
>
> > + rmdir -p --ignore-fail-on-non-empty $(DESTDIR)$(libdir)
>
> > + rmdir -p --ignore-fail-on-non
On Fri, Jun 20, 2014 at 08:40:49AM -0700, Josef Bacik wrote:
> On 06/19/2014 05:53 PM, Marc MERLIN wrote:
> >On Thu, Jun 19, 2014 at 03:50:16PM -0700, Josef Bacik wrote:
> >>Ok same drill as before, reset and apply this, hopefully no panic this
> >>time
> >>
> >>
> >>diff --git a/fs/btrfs/relocati
> I don't know all states of this file system, and copies you have. Right now
> the earliest copy is obviously broken, and the latest copy is probably more
> broken because at the least its csum tree has been blown away meaning there's
> no checksums to confirm whether any data extracted/copied
On Jun 25, 2014, at 1:47 AM, Hugo Mills wrote:
>
> The question is, why? If you have enough disk media errors to make
> it worth using multiple copies, then your storage device is basically
> broken and needs replacing, and it can't really be relied on for very
> much longer.
Yeah basically -
On Jun 24, 2014, at 11:53 PM, Mike Hartman wrote:
>> Does this version's btrfs-image allow you to make an image of the file
>> system?
>
> Nope, same errors and no output.
>
>> https://btrfs.wiki.kernel.org/index.php/Restore
>>
>> Your superblocks are good according to btrfs rescue super-rec
kcalloc manages count*sizeof overflow.
Cc: Chris Mason
Cc: Josef Bacik
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Fabian Frederick
---
fs/btrfs/compression.c | 2 +-
fs/btrfs/ctree.c| 8
fs/btrfs/disk-io.c | 2 +-
fs/btrfs/free-space-cache.c | 2 +-
fs/bt
Imran Geriskovan posted on Wed, 25 Jun 2014 15:01:49 +0200 as excerpted:
> Note that gdisk gives default 8 sector alignment value for AF disks.
> That is 'sector' meant by gdisk is 'Logical Sector'!
> Sufficiently determined user may create misaligned partitions by playing
> with alignment value a
On Wed, 2014-06-25 at 08:47 +0100, Hugo Mills wrote:
>This has variously been possible and not over the last few years. I
> think it's finally come down on the side of "not",
I think that would really be a loss... :(
>The question is, why?
Well imagine you have some computer which can on
On 6/25/14, Hugo Mills wrote:
>> Storage is pretty cheap now, and to have multiple copies in btrfs is
>> something that I think could be used a lot. I know I will use multiple
>> copies of my data if made possible.
>The question is, why? If you have enough disk media errors to make
> it worth
On 06/25/2014 03:09 PM, Tamas Papp wrote:
On 06/24/2014 06:37 PM, Chris Murphy wrote:
On Jun 24, 2014, at 1:52 AM, Tamas Papp wrote:
On 06/22/2014 07:10 PM, Tamas Papp wrote:
On 06/20/2014 02:04 AM, George Mitchell wrote:
Hello Tamas,
I think it would help to provide more information tha
On 06/24/2014 06:37 PM, Chris Murphy wrote:
On Jun 24, 2014, at 1:52 AM, Tamas Papp wrote:
On 06/22/2014 07:10 PM, Tamas Papp wrote:
On 06/20/2014 02:04 AM, George Mitchell wrote:
Hello Tamas,
I think it would help to provide more information than what you have posted.
"open_ctree" can c
On 6/23/14, Martin K. Petersen wrote:
> Anyway. The short answer is that Linux will pretty much always do I/O in
> multiples of the system page size regardless of the logical block size
> of the underlying device. There are a few exceptions to this such as
> direct I/O, legacy filesystems using bu
Daniel Landstedt posted on Wed, 25 Jun 2014 09:25:57 +0200 as excerpted:
> Will it be possible to use DUP for data as well as for metadata on a
> single device?
See Hugo's answer for the general case. I've learned a lot from him. =:^)
While I believe and as he says the general answer is no, the
The chunk-recover.c/BTRFS_NUM_MIRRORS in the userspace means
the same thing as ctree.h/BTRFS_MAX_MIRRORS in the kernelspace,
so to stay consistent with the kernelspace, just make this movement
in the userspace:
chunk-recover.c/BTRFS_NUM_MIRRORS
===>
ctree.h/BTRFS_MAX
Hi,
I got these during heavy IO (fs indexing):
[175200.080150] INFO: task akonadi_baloo_i:6489 blocked for more than 480
seconds.
[175200.080160] Not tainted 3.16.0-rc2-12.gfc9498b-desktop+ #2
[175200.080164] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[17520
>It'll be exactly 2 copies at the moment. Note that performance on
> an SSD will at least halve, and performance on a rotational device
> will probably suck quite badly. Neither will help you in the case of a
> full-device failure. You still need backups, kept on a separate machine.
>
Write pe
On Wed, Jun 25, 2014 at 09:25:57AM +0200, Daniel Landstedt wrote:
> Will it be possible to use DUP for data as well as for metadata on a
> single device?
This has variously been possible and not over the last few years. I
think it's finally come down on the side of "not", but by all means try
i
Hi Satoru,
On Wed, Jun 25, 2014 at 04:25:01PM +0900, Satoru Takeuchi wrote:
> Hi Liu,
>
> (2014/06/24 16:39), Liu Bo wrote:
> > The reproducer is
> >
> > $ mkfs.btrfs D1 D2 D3 -mraid5
> > $ mkfs.ext4 D2 && mkfs.ext4 D3
> > $ mount D1 /btrfs -odegraded
>
> Tested-by: Satoru Takeuchi
>
> Here is
Will it be possible to use DUP for data as well as for metadata on a
single device?
And if so, am I going to be able to specify more than 1 copy of the data?
Storage is pretty cheap now, and to have multiple copies in btrfs is
something that I think could be used a lot. I know I will use multiple
Hi Liu,
(2014/06/24 16:39), Liu Bo wrote:
> The reproducer is
>
> $ mkfs.btrfs D1 D2 D3 -mraid5
> $ mkfs.ext4 D2 && mkfs.ext4 D3
> $ mount D1 /btrfs -odegraded
Tested-by: Satoru Takeuchi
Here is the result of the last mount.
===
...
mount: wrong fs type, bad option, bad superblock on /dev/vdb1
35 matches
Mail list logo
