ices, then it is asured that
the devices in cloned @fs_devices are not treated as valid devices.
o If a device disappears and reappears without any touch, its
@bdev->bd_dev may change, so we have to re-insert it into the rb_root.
Signed-off-by: Gui Hecheng
---
changelog
v1->
Oh, sorry, some format style problems...
let me resend a new one.
On Thu, 2015-01-15 at 16:53 +0800, Gui Hecheng wrote:
> There is a global list @fs_uuids to keep @fs_devices object
> for each created btrfs. But when a btrfs becomes "empty"
> (all devices belong to it are gon
ices, then it is asured that
the devices in cloned @fs_devices are not treated as valid devices.
o If a device disappears and reappears without any touch, its
@bdev->bd_dev may change, so we have to re-insert it into the rb_root.
Signed-off-by: Gui Hecheng
---
changelog
v1->
; @btrfs_device.
A special case to deal with is that a block device is unplugged and
replugged, then it appears with a new @bdev->bd_dev as devnum.
In this case, we should remove the older since we should have a new
one for that block device already.
Signed-off-by: Gui Hecheng
---
fs/b
On Wed, 2015-01-14 at 16:22 +0100, David Sterba wrote:
> On Wed, Jan 14, 2015 at 04:18:54PM +0800, Gui Hecheng wrote:
> > Move the branch that is unrelated to the result of io_ctl_init() before
> > the function call, so we can save a kmalloc() & kfree() pair in that
> > br
Move the branch that is unrelated to the result of io_ctl_init() before
the function call, so we can save a kmalloc() & kfree() pair in that
branch.
Signed-off-by: Gui Hecheng
---
fs/btrfs/free-space-cache.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --g
The xfstests btrfs/072 reports uncorrectable read errors in dmesg,
because scrub forgets to use commit_root for parity scrub routine
and scrub attempts to scrub those extents items whose contents are
not fully on disk.
To fix it, we just add the @search_commit_root flag back.
Signed-off-by: Gui
[ping]
On Wed, 2014-12-10 at 15:39 +0800, Gui Hecheng wrote:
> The following patch:
> btrfs: remove empty fs_devices to prevent memory runout
>
> introduces @valid_dev_root aiming at recording @btrfs_device objects that
> have corresponding block devices with btrfs.
> But
On Fri, 2015-01-02 at 17:21 +0100, David Sterba wrote:
> On Fri, Jan 02, 2015 at 05:12:04PM +0100, David Sterba wrote:
> > On Thu, Jan 01, 2015 at 08:27:55PM -0700, Chris Murphy wrote:
> > > Small problem with the rendering of this commit
> > > d4ef1a06f8be623ae94e4d498c306e8dd1605bef, when I use '
o removed an unecessary INIT_LIST_HEAD after LIST_HEAD
o merge a declare & INIT_LIST_HEAD pair into one LIST_HEAD
Signed-off-by: Gui Hecheng
---
fs/btrfs/free-space-cache.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-s
Signed-off-by: Gui Hecheng
Reviewed-by: Satoru Takeuchi
---
changelog
v1->v2:
s/\'E\'(EiB)/or \'E\'(EiB)/ as suggested by Satoru, thanks.
v2->v3:
replace confusing format 'K'(KiB) etc. Thanks, David.
---
Do
On Mon, 2014-12-29 at 17:07 +0100, David Sterba wrote:
> On Mon, Dec 22, 2014 at 03:22:53PM +0800, Gui Hecheng wrote:
> > Signed-off-by: Gui Hecheng
> > Reviewed-by: Satoru Takeuchi
> > ---
> > changelog
> > v1->v2: s/\'E\'(EiB)
On Thu, 2014-12-25 at 15:49 +0900, Satoru Takeuchi wrote:
> On 2014/12/25 10:16, Gui Hecheng wrote:
> > Now, if exec:
> > # btrfs-debug-tree
> > it echos:
> > : Superblock bytenr is larger than device size
> >
> > But it is quite misleading, becaus
ock device
: 'usage: btrfs-debug-tree [options] device
Signed-off-by: Gui Hecheng
---
btrfs-debug-tree.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/btrfs-debug-tree.c b/btrfs-debug-tree.c
index e46500d..7f079a9 100644
--- a/btrfs-debug-tree.c
+++ b/btrfs-debug-tree.c
@@ -179,6 +179
The check_arg_type() function does quite generic thing,
move it to utils.c.
Signed-off-by: Gui Hecheng
---
cmds-filesystem.c | 32
utils.c | 32
utils.h | 1 +
3 files changed, 33 insertions(+), 32 deletions
search, strerror(errno));
> - return 1;
> - }
> -
> - search = path;
> + if (realpath(search, path))
> + search = path;
This looks nice and stay consistent with the behavior
On Mon, 2014-12-22 at 19:39 +0900, Satoru Takeuchi wrote:
> Sorry, I forgot to add Signed-off-by line.
>
> ---
> From: Satoru Takeuchi
>
> "notused" is not necessary. Set 1 to the first entry is enough.
Hi Satoru,
Actually, the struct is copied from the kernel header
include/uapi/linux/btrfs.h
Signed-off-by: Gui Hecheng
Reviewed-by: Satoru Takeuchi
---
changelog
v1->v2: s/\'E\'(EiB)/or \'E\'(EiB)/ as suggested by Satoru, thanks.
---
Documentation/btrfs-filesystem.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/
Signed-off-by: Gui Hecheng
---
Documentation/btrfs-filesystem.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/btrfs-filesystem.txt
b/Documentation/btrfs-filesystem.txt
index a8f2972..f2bd50d 100644
--- a/Documentation/btrfs-filesystem.txt
+++ b
home/sat/mnt/
> ro=false
> label=
> # ./btrfs-new prop get /
> ro=false
> label=foo# label is displayed
> ===========
>
> Signed-off-by: Satoru Takeuchi
> Reported-by: Naohiro Aota
Looks good to me.
Reviewed-by: Gui Hecheng
T
On Thu, 2014-12-18 at 15:42 +0900, Satoru Takeuchi wrote:
> From: Satoru Takeuchi
>
> When "/" is Btrfs, "btrfs property /" regards it
> as non-root by mistake.
>
> check_is_root() regards @object as a file system root if
> the following two conditions are satisfied.
>
> a) Both @object and i
On Thu, 2014-12-18 at 15:09 +0900, Satoru Takeuchi wrote:
> From: Satoru Takeuchi
> Date: Thu, 18 Dec 2014 14:35:22 +0900
>
> @tmp is freed even if its allocation fails.
>
> Signed-off-by: Satoru Takeuchi
>
> ---
> cmds-property.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 delet
When we want to delete a subvol, we first check to see whether it is
a subvolume or not. After the check, we are sure that it is a valid
subvol, don't have to check its name.
Signed-off-by: Gui Hecheng
---
cmds-subvolume.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a
; @btrfs_device.
A special case to deal with is that a block device is unplugged and
replugged, then it appears with a new @bdev->bd_dev as devnum.
In this case, we should remove the older since we should have a new
one for that block device already.
Signed-off-by: Gui Hecheng
---
fs/b
On Thu, 2014-12-04 at 19:20 +0530, Shriramana Sharma wrote:
> Using SuSE Tumbleweed. Observe:
>
> [samjnaa:~] sudo btrfs fi show
> root's password:
> Label: 'BRIHATII' uuid: 57836428-576e-466b-8a28-7961712867ab
> Total devices 1 FS bytes used 460.19GiB
> devid1 size 931.51GiB
ices, then it is asured that
the devices in cloned @fs_devices are not treated as valid devices.
o If a device disappears and reappears without any touch, its
@bdev->bd_dev may change, so we have to re-insert it into the rb_root.
Signed-off-by: Gui Hecheng
---
changelog
v1->
On Tue, 2014-10-14 at 11:32 +0200, David Sterba wrote:
> On Tue, Oct 14, 2014 at 10:06:16AM +0200, Marc Dietrich wrote:
> > This hasn't landed in an btrfs-progs branch I found. Any update?
>
> I had it tagged for review and found something that needs fixing. The
> PAGE_CACHE_SIZE is hardcoded to 4
For now,
# btrfs fi show /mnt/btrfs
gives info correctly, while
# btrfs fi show /mnt/btrfs/
gives nothing.
This implies that the @realpath() function should be applied to
unify the behavior.
Made a more clear comment right above the call as well.
Signed-off-by: Gui Hecheng
xed another code branch which may return 0 upon error.
3) with 2) applied, the ret = 0 follows can be removed
Signed-off-by: Gui Hecheng
---
cmds-subvolume.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index fa58a24..53eec46 100
ce of space of the gap belongs to a removed empty block group,
and rollback should detect this case, and feel free to continue.
Signed-off-by: Gui Hecheng
---
btrfs-convert.c | 13 +++--
volumes.c | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/btrfs-conver
The @search_cache_extent() only returns the next cache_extent or NULL,
it will never return the previous cache_extent.
So just remove the dead condition for previous cache_extent handle.
Signed-off-by: Gui Hecheng
---
volumes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
On Tue, 2014-11-25 at 02:11 +, boris wrote:
> Hi all,
>
> I was looking for a quick method of testing whether a working directory is a
> subvolume.
>
> Couldn't see an obvious one, so tried 'btrfs show a fail message as expected but returned 0 exit status. Bug?
Hi boris,
I take a quick lo
essary to handle the problem.
But there should be more efficient ways to go, any suggestions?
Thanks,
Gui
> On 11/20/14 10:15 AM, Gui Hecheng wrote:
> > There is a global list @fs_uuids to keep @fs_devices object
> > for each created btrfs. But when a btrfs becomes "empty"
ces in cloned @fs_devices are not treated as valid devices.
Signed-off-by: Gui Hecheng
---
fs/btrfs/super.c | 1 +
fs/btrfs/volumes.c | 181 -
fs/btrfs/volumes.h | 6 ++
3 files changed, 172 insertions(+), 16 deletions(-)
diff --git a/fs/bt
size used path /dev/dm-6
The /dev/dm-* points to lvm volumes, use @canonicalize_path() to convert them
and we will make it through. Of course we should do the same thing for dev stat.
Signed-off-by: Gui Hecheng
---
cmds-device.c | 16 +++-
cmds-filesystem.c | 7 ++-
2 files c
The @fi_args->num_devices in @get_fs_info() does not include seed devices.
We could just correct it by searching the chunk tree and count how
many dev_items there are in total which includes seed devices.
Signed-off-by: Gui Hecheng
---
changelog
v1->v2: adopt more clear functio
gned-off-by: Gui Hecheng
---
changlog
v1->v2: adopt more natural function name:
no_seed_devices ==> has_seed_devices
v2->v3: skip such fs after copied, otherwise such fs won't be shown
---
cmds-filesystem.c | 25 +++--
1 file change
gned-off-by: Gui Hecheng
---
changlog
v1->v2: adopt more natural function name:
no_seed_devices ==> has_seed_devices
---
cmds-filesystem.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-file
On Sat, 2014-11-08 at 19:47 +, Mike Fleetwood wrote:
> On 7 November 2014 18:16, David Sterba wrote:
> > On Fri, Nov 07, 2014 at 10:07:43AM +0800, Gui Hecheng wrote:
> >> The @fi_args->num_devices in @get_fs_info() does not include seed devices.
> >> We could ju
have to check it before write.
Signed-off-by: Gui Hecheng
---
fs/btrfs/scrub.c | 90 +---
1 file changed, 60 insertions(+), 30 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index efa0831..4325bb0 100644
--- a/fs/btrfs/scrub.c
gned-off-by: Gui Hecheng
---
cmds-filesystem.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index 67fe52b..0d49cd1 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@ -795,6 +795,22 @@ out:
re
The @fi_args->num_devices in @get_fs_info() does not include seed devices.
We could just correct it by searching the chunk tree and count how
many dev_items there are in total which includes seed devices.
Signed-off-by: Gui Hecheng
---
*Note*
This is just a temporary workaround to fix t
The following BUG_ON:
BUG_ON(ndevs >= fi_args->num_devices)
is not needed, because it always fails with seed devices present.
Signed-off-by: Gui Hecheng
---
utils.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/utils.c b/utils.c
index f10c178..9bcc1a0 100644
--- a/utils.c
On Wed, 2014-10-29 at 11:45 +0800, Anand Jain wrote:
> this is (most likely) due to patch below,
>
> commit 915902c5002485fb13d27c4b699a73fb66cc0f09
>
> btrfs-progs: fix device missing of btrfs fi show with seed devices
>
>
> Could you try to back out the
fter @btrfs_can_kernel() has finished showing all mounted ones.
We could skip the mounted fs after @btrfs_can_kernel() is done, then tasks
keeps going on mounted fs while fi show continues on umounted ones separately.
Reported-by: Petr Janecek
Signed-off-by: Gui Hecheng
---
cmds-filesystem.c
Extract the procedure of searching for a target device for fi show
from the @map_seed_devices() function to make it more clear.
Signed-off-by: Gui Hecheng
---
cmds-filesystem.c | 37 -
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/cmds
On Wed, 2014-10-29 at 18:51 +0800, Anand Jain wrote:
> There is a compatibility issue with older kernel with the progs commit id as
> below.
>
> 05cd2907557ba627cfb86e60b214ea6228613a84
Which tree does this commit id belongs to?
I can't find it anywhere?
> So as of now writing to revert the abo
> [PATCH] revert btrfs-progs: do a separate probe for _transient_
> replacing device
>
> Try it out. Lets know.
>
> Thanks
Oh, yes, I've tried your revert patch and I acknowledge that it fixes
the problem.
So please *ignore* my patch David, sorry for the noise.
-Gui
>
On Tue, 2014-10-28 at 16:42 +0800, Anand Jain wrote:
>
>
> On 28/10/2014 12:03, Gui Hecheng wrote:
> > On Thu, 2014-10-23 at 21:36 +0800, Anand Jain wrote:
> >>
> >>there is no point in re-creating so many btrfs kernel's logic in user
> >>
s really interesting.
But how to store the seed/sprout relationships so that we can fetch them
correctly for umounted btrfs?
-Gui
>
> On 10/23/14 16:52, Gui Hecheng wrote:
> > On Thu, 2014-10-23 at 16:13 +0800, Anand Jain wrote:
> >>
> >> Some of the disks o
On Thu, 2014-10-23 at 15:23 +0200, Petr Janecek wrote:
> Hello Gui,
>
> > Oh, it seems that there are btrfs with missing devs that are bringing
> > troubles to the @open_ctree_... function.
>
> what do you mean by "missing devs"? I have no degraded fs.
Ah, sorry, I'm too focused on the problem
On Thu, 2014-10-23 at 16:13 +0800, Anand Jain wrote:
>
> Some of the disks on my system were missing and I was able to hit
> this issue.
>
>
>
> Check tree block failed, want=12582912, have=0
> read block failed check_tree_block
> Couldn't read chunk root
> warning devid 2 not f
oblem with device under replacing.
Signed-off-by: Gui Hecheng
---
utils.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/utils.c b/utils.c
index f10c178..0ba2b26 100644
--- a/utils.c
+++ b/utils.c
@@ -1881,12 +1881,15 @@ int get_fs_info(char *path, s
On Thu, 2014-09-04 at 20:02 +0800, Anand Jain wrote:
>
>
> On 09/04/2014 05:58 PM, David Sterba wrote:
> > On Mon, Aug 18, 2014 at 04:38:18PM +0800, Anand Jain wrote:
> >> ioctl BTRFS_IOC_FS_INFO return num_devices which does _not_ include seed
> >> device, But the following ioctl BTRFS_IOC_DEV_I
On Thu, 2014-10-16 at 11:26 +0200, Stefan Behrens wrote:
> On Thu, 16 Oct 2014 09:53:37 +0800, Gui Hecheng wrote:
> > The @btrfs_ioctl_get_dev_stats fails to pad to 1k as descripted,
> > actually it valuates to 1032 bytes.
> > The corresponding userspace change follows this ch
is a valid mntpnt by calling
@find_mount_root() to prevent this silent damage.
Signed-off-by: Gui Hecheng
---
cmds-device.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/cmds-device.c b/cmds-device.c
index a728f21..65815c3 100644
--- a/cmds-device.c
+++ b/cmds-devic
The @btrfs_ioctl_get_dev_stats fails to pad to 1k as descripted,
actually it valuates to 1032 bytes.
The corresponding userspace change follows this change.
Signed-off-by: Gui Hecheng
---
include/uapi/linux/btrfs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi
The @btrfs_ioctl_get_dev_stats fails to pad to 1k as descripted,
actually it valuates to 1032 bytes.
Correct it following the kernel patch.
Signed-off-by: Gui Hecheng
---
ioctl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ioctl.h b/ioctl.h
index f0fc060..6657f8f 100644
Check ping
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
his commit, btrfs-debug-tree will report unable
to open the device.
Signed-off-by: Gui Hecheng
---
*Note*
This should be after patch:
Btrfs-progs: fsck: disallow partial opening if critical \
roots corrupted
---
volumes.c | 11 +--
1 fil
with the newest generation
Signed-off-by: Gui Hecheng
---
changelog
v1->v2: o add multi-level of seeds handle
o add dev replace handle
---
cmds-filesystem.c | 294 +-
volumes.c | 1 +
volumes.h | 2
ignment every time before we are going to
fetch the next @len and after the former piece of data is decompressed.
If the current page that we reach has less than 4 bytes left,
then we should fetch the next @len at the start of next page.
Signed-off-by: Gui Hecheng
Reviewed-by: Marc Dietrich
---
On Tue, 2014-09-23 at 10:25 +0800, Gui Hecheng wrote:
> When runing restore under lzo compression, "bad compress length"
> problems are encountered.
> It is because there is a page align problem with the @decompres
ignment every time before we are going to
fetch the next @len and after the former piece of data is decompressed.
If the current page that we reach has less than 4 bytes left,
then we should fetch the next @len at the start of next page.
Signed-off-by: Gui Hecheng
Reviewed-by: Marc Dietrich
---
On Mon, 2014-09-22 at 15:41 +0200, David Sterba wrote:
> On Mon, Sep 22, 2014 at 04:58:26PM +0800, Gui Hecheng wrote:
> > So we check page alignment every time before we are going to
> > fetch the next @len and after the former piece of data is decompressed.
> > If the curre
ignment every time before we are going to
fetch the next @len and after the former piece of data is decompressed.
If the current page that we reach has less than 4 bytes left,
then we should fetch the next @len at the start of next page.
Signed-off-by: Gui Hecheng
Reviewed-by: Marc Dietrich
---
On Mon, 2014-09-22 at 10:49 +0200, Marc Dietrich wrote:
> Am Montag, 22. September 2014, 16:33:56 schrieb Gui Hecheng:
> > On Mon, 2014-09-22 at 10:19 +0200, Marc Dietrich wrote:
> > > Hi,
> > >
> > > Am Freitag, 19. September 2014, 09:30:30 schrieb Gui Heche
On Mon, 2014-09-22 at 10:44 +0200, Marc Dietrich wrote:
> Am Montag, 22. September 2014, 16:29:28 schrieb Gui Hecheng:
> > When runing restore under lzo compression, "bad compress length"
> > problems are encountered.
> > It is because there is a page align problem w
On Mon, 2014-09-22 at 10:19 +0200, Marc Dietrich wrote:
> Hi,
>
> Am Freitag, 19. September 2014, 09:30:30 schrieb Gui Hecheng:
> > On Thu, 2014-09-18 at 12:47 +, Zooko Wilcox-OHearn wrote:
> > > Thank you! I will try to restore using this patch.
> > >
>
ignment every time before we are going to
fetch the next @len and after the former piece of data is decompressed.
If the current page that we reach has less than 4 bytes left,
then we should fetch the next @len at the start of next page.
Signed-off-by: Marc Dietrich
Signed-off-by: Gui Hecheng
---
On Thu, 2014-09-18 at 12:47 +, Zooko Wilcox-OHearn wrote:
> Thank you! I will try to restore using this patch.
>
> What branch of what btrfs tools git repo should I apply the patch to?
>
> Regards,
>
> Zooko
At least I think the following repo/v3.17.x branch has all
restore-related patches
On Thu, 2014-09-18 at 11:25 +0200, Marc Dietrich wrote:
> Am Donnerstag, 18. September 2014, 17:10:54 schrieb Gui Hecheng:
> > On Thu, 2014-09-18 at 10:25 +0200, Marc Dietrich wrote:
> > > Hello Gui,
> > >
> > > Am Donnerstag, 18. September 2014, 11:34:43 schr
On Thu, 2014-09-18 at 05:01 -0400, Wang Shilong wrote:
> super-recover collects btrfs devices infomation using existed
> functions scan_one_devices().
>
> Problem is fs_devices is freed twice in close_ctree() and
> free_recover_superblock() for super correction path.
>
> Fix this problem by check
On Thu, 2014-09-18 at 10:25 +0200, Marc Dietrich wrote:
> Hello Gui,
>
> Am Donnerstag, 18. September 2014, 11:34:43 schrieb Gui Hecheng:
> > When runing restore under lzo compression, "bad compress length"
> > problems are encountered.
> > It is because t
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 s
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
to the page-aligned start position to read
the len of next piece of data when "bad compress length" is encounterd.
If we still get bad compress length in this case, then there is a
real "bad compress length", and we shall report error.
Signed-off-by: Gui Hecheng
---
cmds-restor
the seeding devices properly, so
we can make use of it to find seeding devices.
We call @open_ctree on every block device with a btrfs on it,
and all devices under the opening filesystem including the seed devices
will be ready to be shown.
Signed-off-by: Gui Hecheng
---
cmds-filesystem.c |
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
On Mon, 2014-09-15 at 16:59 +0200, Karl-Philipp Richter wrote:
> Hi together,
> I'm currently encountering another issue with `btrfs rescue
> chunk-recover`. After some seconds of maximal I/O activity, the program
> is idle for some seconds and then prints
>
> The chunks in memory can not m
On Fri, 2014-09-12 at 14:56 +0900, Satoru Takeuchi wrote:
> Hi Gui,
>
> (2014/09/12 10:15), Gui Hecheng wrote:
> > For btrfs fi show, -d|--all-devices & -m|--mounted will
> > overwrite each other, so if specified both, let the user
> > know that he shoul
For btrfs fi show, -d|--all-devices & -m|--mounted will
overwrite each other, so if specified both, let the user
know that he should not use them at the same time.
Signed-off-by: Gui Hecheng
---
changelog:
v1->v2: add option conflict descriptions to manpage and usage.
---
Docume
For btrfs fi show, -d|--all-devices & -m|--mounted will
overwrite each other, so if specified both, let the user
know that he should not use them at the same time.
Signed-off-by: Gui Hecheng
---
cmds-filesystem.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --g
quot;,
there is no need to use @set_argv0() before check_argc_* to
repair the prompt tool name before "too few arguments".
Signed-off-by: Gui Hecheng
---
cmds-restore.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/cmds-restore.c b/cmds-restore.c
index f909429..38a131e 100644
-
The btrfs_free_path calls btrfs_release_path internally.
Signed-off-by: Gui Hecheng
---
disk-io.c | 1 -
file-item.c | 1 -
inode-map.c | 2 --
3 files changed, 4 deletions(-)
diff --git a/disk-io.c b/disk-io.c
index 9e44f10..0f9f374 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -628,7 +628,6
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
The restore tool should only print info of the restoring process
in verbose mode with -v option specified.
Signed-off-by: Gui Hecheng
---
cmds-restore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmds-restore.c b/cmds-restore.c
index e9ec472..f909429 100644
--- a/cmds
On Fri, 2014-08-29 at 16:49 +0200, David Sterba wrote:
> On Thu, Aug 28, 2014 at 10:25:55AM +0800, Gui Hecheng wrote:
> > The printf of @offset enlightens the user little.
> > And the restore cmd is not a debugging tool, so just
> > remove the debug-info-like printf.
>
BTW，there is a develop branch from the btrfs-progs's maintainer David:
http://github.com/kdave/btrfs-progs.git
Maybe you'd like to try it, it may make some differences.
-Gui
On Mon, 2014-08-25 at 05:08 +, Zooko Wilcox-OHearn wrote:
> Dear people of linux-btrfs:
>
> Thank you for btrfs! It i
On Mon, 2014-08-25 at 05:08 +, Zooko Wilcox-OHearn wrote:
> Dear people of linux-btrfs:
>
> Thank you for btrfs! It is a beautiful thing. I say that in spite of
> the fact that it seems to have failed and eaten some of my data.
>
> I'm writing with two purposes: to get help and advice in reco
he len of the inline item.
So in the compressed situation, use the len of the inline item.
Signed-off-by: Gui Hecheng
---
cmds-restore.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/cmds-restore.c b/cmds-restore.c
index bb72311..e94592c 100644
--- a/cmds-restore.c
++
When entering the next level node, the @next_leaf in restore forgets to
start at the first slot. Just reset it to the first one.
Signed-off-by: Gui Hecheng
---
cmds-restore.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmds-restore.c b/cmds-restore.c
index e94592c..918f1fb 100644
--- a
The printf of @offset enlightens the user little.
And the restore cmd is not a debugging tool, so just
remove the debug-info-like printf.
Signed-off-by: Gui Hecheng
---
cmds-restore.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/cmds-restore.c b/cmds-restore.c
index 918f1fb..648fbc9
On Mon, 2014-08-25 at 10:58 +0200, Marc Dietrich wrote:
> Am Freitag 22 August 2014, 10:42:18 schrieb Marc Dietrich:
> > Am Freitag, 22. August 2014, 14:43:45 schrieb Gui Hecheng:
> > > On Thu, 2014-08-21 at 16:19 +0200, Marc Dietrich wrote:
> > > > Am Donnerstag, 21.
On Fri, 2014-08-22 at 10:42 +0200, Marc Dietrich wrote:
> Am Freitag, 22. August 2014, 14:43:45 schrieb Gui Hecheng:
> > On Thu, 2014-08-21 at 16:19 +0200, Marc Dietrich wrote:
> > > Am Donnerstag, 21. August 2014, 17:52:16 schrieb Gui Hecheng:
> > > > On Mon, 2
On Thu, 2014-08-21 at 16:19 +0200, Marc Dietrich wrote:
> Am Donnerstag, 21. August 2014, 17:52:16 schrieb Gui Hecheng:
> > On Mon, 2014-08-18 at 11:25 +0200, Marc Dietrich wrote:
> > > Hi,
> > >
> > > I did a checkout of the latest btrfs progs to repair my dam
On Mon, 2014-08-18 at 11:25 +0200, Marc Dietrich wrote:
> Hi,
>
> I did a checkout of the latest btrfs progs to repair my damaged filesystem.
> Running btrfs restore gives me several failed to inflate: -6 and crashes with
> some memory corruption. I ran it again with valgrind and got:
>
> valgr
On Thu, 2014-08-21 at 10:14 +0200, Marc Dietrich wrote:
> Hi Gui,
>
> Am Donnerstag, 21. August 2014, 11:35:36 schrieb Gui Hecheng:
> > A memory problem reported by valgrind as follows:
> > === Syscall param pwrite64(buf) points to uninitialised byte(s)
> > When
shorter than the sizeof(buf), so valgrind report
uninitialised byte(s).
We could use calloc to repalce malloc and clear this WARNING away.
Reported-by: Marc Dietrich
Signed-off-by: Gui Hecheng
---
cmds-restore.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmds-restore.c b
1 - 100 of 256 matches
Mail list logo
