Mention that a target path argument is mandatory unless
the -l option is supplied. Also mention about the existence
of the -l option, which was previously not announced.
$ btrfs restore -v /dev/sdb3
usage: btrfs restore [options] device
Try to restore files from a damaged filesystem
I created a bug:
https://bugzilla.kernel.org/show_bug.cgi?id=60544
Am 08.07.2013 15:24, schrieb Josef Bacik:
On Mon, Jul 08, 2013 at 08:46:17AM +0200, Franziska Näpelt wrote:
Hi everybody,
we are using a btrfs RAID 1 with four 2TB hard drives on a Debian 7.1
(Kernel 3.9.6).
After about one
Currently num_tolerated_disk_barrier_failures gets the value of
fs_devices-num_devices in the RAID6 case. But, RAID6 can tolerate only
two simultaneous failures, so set it to 2.
CC: Stefan Behrens sbehr...@giantdisaster.de
Signed-off-by: Ilya Dryomov idryo...@gmail.com
---
fs/btrfs/disk-io.c |
On Wed, 10 Jul 2013 14:54:30 +0300, Ilya Dryomov wrote:
Currently num_tolerated_disk_barrier_failures gets the value of
fs_devices-num_devices in the RAID6 case. But, RAID6 can tolerate only
two simultaneous failures, so set it to 2.
CC: Stefan Behrens sbehr...@giantdisaster.de
On Wed, Jul 10, 2013 at 12:54:44PM +1000, Russell Coker wrote:
There are two uses of backups, recovering from user errors (IE deleting the
wrong file) and recovering from sysadmin errors or hardware failures (IE
disks
are dead or wiped). For the former use I'm mainly using BTRFS snapshots
On Tue, Jul 09, 2013 at 01:24:43PM -0700, Zach Brown wrote:
The original codes don't handle error gracefully and some places
forget to free memory. We can allocate memory before calling pretty_sizes(),
for example, we can use static memory allocation and we don't have to deal
with memory
From: Zach Brown z...@redhat.com
From: Zach Brown z...@redhat.com
We don't need callers to manage string storage for each pretty_sizes()
call. We can use a macro to have per-thread and per-call static storage
so that pretty_sizes() can be used as many times as needed in printf()
arguments
Hello David,
From: Zach Brown z...@redhat.com
duplicate information.
From: Zach Brown z...@redhat.com
We don't need callers to manage string storage for each pretty_sizes()
call. We can use a macro to have per-thread and per-call static storage
so that pretty_sizes() can be used as
When there are files that have parts shared with snapshots, the
restore command was incorrectly restoring them, as it was not
taking into account the offset and number of bytes fields from
the file extent item. Besides leaving the recovered file corrupt,
it was also inneficient as it read and
On Wed, Jul 10, 2013 at 11:31:17PM +0800, Wang Shilong wrote:
Hello David,
From: Zach Brown z...@redhat.com
duplicate information.
git-send-email tricked me, the line is not present in thre tree
From: Zach Brown z...@redhat.com
We don't need callers to manage string storage for
Neat trick! A few neat-picks below.
Indeed, those are all good fixes.
As these are only trivial changes I'll fix them at commit time.
Great, thanks David!
- z
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
When there are files that have parts shared with snapshots, the
restore command was incorrectly restoring them, as it was not
taking into account the offset and number of bytes fields from
the file extent item. Besides leaving the recovered file corrupt,
it was also inneficient as it read and
On Tue, Jul 09, 2013 at 07:49:53PM +0100, Filipe David Borba Manana wrote:
The module cmds-restore.c was defining its own next_leaf()
function, which did exactly the same as btrfs_next_leaf()
from ctree.c.
This has been removed by Eric's patch present in the integration
branches:
Btrfs-progs:
Sorry to be a pain in the arse at this late stage of the patch, but
I've only just noticed.
On Wed, Jul 10, 2013 at 04:30:15PM +0200, David Sterba wrote:
static char *size_strs[] = { , KB, MB, GB, TB,
- PB, EB, ZB, YB};
-char *pretty_sizes(u64 size)
+
When there are files that have parts shared with snapshots, the
restore command was incorrectly restoring them, as it was not
taking into account the offset and number of bytes fields from
the file extent item. Besides leaving the recovered file corrupt,
it was also inneficient as it read and
On Wed, Jul 10, 2013 at 5:12 PM, David Sterba dste...@suse.cz wrote:
On Tue, Jul 09, 2013 at 07:49:53PM +0100, Filipe David Borba Manana wrote:
The module cmds-restore.c was defining its own next_leaf()
function, which did exactly the same as btrfs_next_leaf()
from ctree.c.
This has been
On Mon, Jul 08, 2013 at 11:54:46PM +0200, David Sterba wrote:
On Thu, Jul 04, 2013 at 01:51:38PM +0400, Andrew Vagin wrote:
We are not first who suffer from this problem:
https://bugzilla.redhat.com/show_bug.cgi?id=711881
http://marc.info/?l=linux-btrfsm=130074451403261
When there are files that have parts shared with snapshots, the
restore command was incorrectly restoring them, as it was not
taking into account the offset and number of bytes fields from
the file extent item. Besides leaving the recovered file corrupt,
it was also inneficient as it read and
On Wed, Jul 10, 2013 at 05:16:23PM +0100, Hugo Mills wrote:
Sorry to be a pain in the arse at this late stage of the patch, but
I've only just noticed.
No worries, good to have this one fixed.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a
As implemented now, we use 1024 based units but reporting 1000 based,
let's finally fix that and add optional unit bases later.
Signed-off-by: David Sterba dste...@suse.cz
---
utils.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/utils.c b/utils.c
index bce06f1..2e24cb0
On Wed, Jul 10, 2013 at 09:31:05AM -0700, Mark Fasheh wrote:
As far as I can tell we'll be carrying this patch until a better
solution is possible.
When that will happen, I don't know.
--Mark
Well, what do I get when I pretend I don't care any more? The little voice
in my head says
On Wed, Jul 10, 2013 at 10:45:45AM -0700, Mark Fasheh wrote:
Well, what do I get when I pretend I don't care any more? The little voice
in my head says keep plugging away. Here's another attempt at fixing this
problem in a sane manner. Basically, this time we're adding a flag to
s_flags which
On Sun, Jun 30, 2013 at 12:35:09PM -0500, Mitch Harder wrote:
There's been a parallel effort to incorporate a general set of lz4
patches in the kernel.
I see these patches are currently queued up in the linux-next tree, so
we may see them in the 3.11 kernel.
The patches are now merged into
This change adds a new option to the restore command, named -x,
that makes it restore file extented attributes too. This is an
optional behaviour and it's disabled by default.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
cmds-restore.c | 113
This change adds a new option to the restore command, named -x,
that makes it restore file extented attributes too. This is an
optional behaviour and it's disabled by default.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
V2: added missing new line at end of error message.
This change adds a new option to the restore command, named -x,
that makes it restore file extented attributes too. This is an
optional behaviour and it's disabled by default.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
V2: added missing new line at end of error message.
V3:
This change adds a new option to the restore command, named -x,
that makes it restore file extented attributes too. This is an
optional behaviour and it's disabled by default.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
V2: added missing new line at end of error message.
V3:
It is unnecessary to unlock the extent by the page size, we can do it
in batches, it makes the random read be faster by ~6%.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent_io.c | 70 ++--
1 file changed, 40 insertions(+), 30
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent_io.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 4bfbcc5..c9b28cf 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2503,7
Before applying this patch, we cached the csum value into the extent state
tree when reading some data from the disk, this operation increased the lock
contention of the state tree.
Now, we just store the csum value into the bio structure or other unshared
structure, so we can reduce the lock
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent_io.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index f8586a9..4bfbcc5 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@
31 matches
Mail list logo
