Hi Josef,
On Wed, Jun 26, 2013 at 5:16 PM, Alex Lyakas
wrote:
> Hi Josef,
> Can you please help me with another question.
>
> I am looking at your patch:
> Btrfs: fix chunk allocation error handling
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/li
On Sun, Jun 30, 2013 at 2:36 PM, Josef Bacik wrote:
> On Sun, Jun 30, 2013 at 11:29:14AM +0300, Alex Lyakas wrote:
>> Hi Josef,
>>
>> On Wed, Jun 26, 2013 at 5:16 PM, Alex Lyakas
>> wrote:
>> > Hi Josef,
>> > Can you please help me with another q
(btrfs_header_backref_rev(root->node) <
> + BTRFS_MIXED_BACKREF_REV)
> + ret = btrfs_drop_snapshot(root, NULL, 0, 0);
> + else
> + ret = btrfs_drop_snapshot(root, NULL, 1, 0);
> + /*
> +* If
Hi David,
On Thu, Jul 4, 2013 at 8:03 PM, David Sterba wrote:
> On Thu, Jul 04, 2013 at 06:29:23PM +0300, Alex Lyakas wrote:
>> > @@ -7363,6 +7365,12 @@ int btrfs_drop_snapshot(struct btrfs_root *root,
>> > wc->reada_count = BTRFS_NODEPTRS_PER_BLOCK(root);
&g
Hi,
On Thu, Jul 4, 2013 at 10:52 PM, Alex Lyakas
wrote:
> Hi David,
>
> On Thu, Jul 4, 2013 at 8:03 PM, David Sterba wrote:
>> On Thu, Jul 04, 2013 at 06:29:23PM +0300, Alex Lyakas wrote:
>>> > @@ -7363,6 +7365,12 @@ int btrfs_drop_snapshot(struct btrfs_root *root,
&g
e evicted the extent buffer
> from cache. Thanks,
>
> Reported-by: Alex Lyakas
> Signed-off-by: Josef Bacik
> ---
> fs/btrfs/extent-tree.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> ind
Thanks for posting that patch, Josef.
On Mon, Jul 15, 2013 at 6:59 PM, Josef Bacik wrote:
>
> Alex pointed out a problem and fix that exists in the drop one snapshot at
> a
> time patch. If we decide we need to exit for whatever reason (umount for
> example) we will just ex
btrfs_item_key_to_cpu(eb, &block->key, 0);
> --
> 1.7.7.6
>
> --
> 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.or
pt(root, CHECK_INTEGRITY))
> --
> 1.7.7.6
>
> --
> 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
Alex.
--
To
do_chunk_alloc returns 1 when it succeeds to allocate a new chunk.
But flush_space will not convert this to 0, and will also return 1.
As a result, reserve_metadata_bytes will think that flush_space failed,
and may potentially return this value "1" to the caller (depends how
reserve_metadata_bytes
Hi Liu,
I was studying on how block reservation works, and making some
modifications in reserve_metadata_bytes to understand better what it
does. Then suddenly I saw this problem. I guess it depends on which
value of "flush" parameter is passed to reserve_metadata_bytes.
Alex.
On
So it will return -ENOSPC.
Signed-off-by: Alex Lyakas
Reviewed-by: Josef Bacik
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 4b89680..1ba3f0d 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4727,7 +4727,7 @@ static int flush_space(struct btrfs_
__btrfs_end_transaction() that find_free_extent() does after it
completed chunk allocation (although in this case it will use the
transaction that already exists in current->journal_info).
So the deadlock still may happen?
Thanks,
Alex.
>
>
> On Mon, Nov 2, 2015 at 6:52 PM, Chris Mason wrote:
>>
k tree in the context of chunk allocation, which is the
scenario that the rework was meant to avoid.
Can you please point me at what I am missing?
Thanks,
Alex.
On Wed, Jul 22, 2015 at 1:53 AM, Omar Sandoval wrote:
> On Mon, Jul 20, 2015 at 02:56:20PM +0100, fdman...@kernel.org wrote:
&
t see anything
preventing that from happening.
Thanks,
Alex.
On Sun, Oct 25, 2015 at 8:51 PM, wrote:
> From: Filipe Manana
>
> In the kernel 4.2 merge window we had a refactoring/rework of the delayed
> references implementation in order to fix certain problems with qgroups.
>
Hi Filipe,
Thank you for the explanation.
On Sun, Dec 13, 2015 at 5:43 PM, Filipe Manana wrote:
> On Sun, Dec 13, 2015 at 10:51 AM, Alex Lyakas wrote:
>> Hi Filipe Manana,
>>
>> My understanding of selecting delayed refs to run or merging them is
>> far from compl
Thank you, Filipe. Now it is more clear.
Fortunately, in my kernel 3.18 I do not have do_chunk_alloc() calling
btrfs_create_pending_block_groups(), so I cannot hit this deadlock.
But can hit the issue that this call is meant to fix.
Thanks,
Alex.
On Sun, Dec 13, 2015 at 5:45 PM, Filipe Manana
t the extent buffer
doesn't look alright.
The caller up the chain may BUG_ON on this, for example flush_epd_write_bio
will,
but it is better than to have a silent metadata corruption on disk.
Note: this patch has been properly tested on 3.18 kernel only.
Signed-off-by: Alex Lyakas
---
fs/
Thank you, Filipe, for your review.
On Mon, Feb 22, 2016 at 3:05 AM, Filipe Manana wrote:
> On Sun, Feb 21, 2016 at 3:36 PM, Alex Lyakas wrote:
>> csum_dirty_buffer was issuing a warning in case the extent buffer
>> did not look alright, but was still returning success.
>>
wq->normal->max_active = max;
> if (wq->high)
> - workqueue_set_max_active(wq->high->normal_wq, max);
> + wq->high->max_active = max;
> }
>
> void btrfs_set_work_high_priority(struct btrfs_work_struct *work)
> di
sure that on the seconds pass there will be no
pending chunks beyond the new size, so we can shrink to new_size
safely. Is my understanding correct?
Thanks,
Alex.
On Tue, Jun 2, 2015 at 3:43 PM, wrote:
> From: Filipe Manana
>
> When we shrink the usable size of a device (its total_byte
);
bio->bi_end_io = end_io_func;
Thanks,
Alex.
On Wed, Jan 7, 2015 at 12:46 AM, Satoru Takeuchi
wrote:
> Hi Naota,
>
> On 2015/01/06 1:01, Naohiro Aota wrote:
>> After submit_one_bio(), `bio' can go away. However submit_extent_page()
>> leave `bio' referable if sub
;actual_count" before accounting it
in "avg_delayed_ref_runtime"?
Thanks,
Alex.
On Thu, Feb 27, 2014 at 5:56 PM, Josef Bacik wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/27/2014 10:38 AM, 钱凯 wrote:
>> I'm a little confused of what "a
have attached to this
email.
The VM in question runs Debian Jessie, and has 3 BTRFS filesystems, including
the root filesystem. Details are included below.
Any ideas?
Thanks,
Alex
# uname -a
Linux prod-docker-1-a 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5
(2015-10-09) x86_64 GNU
and comment on patches.
Alex.
On Thu, Nov 5, 2015 at 3:08 PM, Holger Hoffstätte
wrote:
> On 10/11/15 20:09, Alex Lyakas wrote:
>> Hi Naota,
>>
>> What happens if btrfs_bio_alloc() in submit_extent_page fails? Then we
>> return -ENOMEM to the caller, but we do not set *bio_re
see that this is not the case.
I am asking because I am doing some profiling of btrfs metadata work under
heavy loads, and I see that sometimes btrfs COW's almost twice more tree
blocks than the total metadata size.
Thanks,
Alex.
--
To unsubscribe from this list: send the line "un
page-cache upto ~6.9GB (judging by btree_inode->i_mapping->nrpages).
But even though the used amount of metadata is less than that, this
re-COW'ing of already-COW'ed blocks seems to cause page-cache
trashing...
Thanks,
Alex.
On Mon, Jul 13, 2015 at 11:27 AM, Filipe David Manana
w
_STATE_UNBLOCKED), and then we can
open a new transaction while the previous is doing
btrfs_write_and_wait_transaction.
That's what I wanted to ask.
Thanks!
Alex.
[1] In my case, btrfs metadata is ~10GBs and the machine has 8GB of
RAM. Due to this we need to read a lot of ebs from disk, as t
uestions make sense?
Thanks!
Alex.
--
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
70 INODE_ITEM 0) itemoff 1970 itemsize 160
inode generation 26 size 1593360 block group 0 mode 100700
links 1
Is this a valid situation, or I should always consider size in
INODE_ITEM as the correct one?
Thanks again,
Alex.
--
To unsubscribe from this list: send the line "unsubsc
Dan Williams wrote:
> The consensus from LSF was that bcache need not invent a new interface
> when md and dm can both do the job. As mentioned in patch 7 this series
> aims to be a minimal conversion. Other refactoring items like
> deprecating register_lock for mddev->reconfig_mutex are deferre
Hugo,
thanks for helping out!
Hopefully, somebody else will address the rest of my questions.
Alex.
On Fri, May 18, 2012 at 4:59 PM, Hugo Mills wrote:
> On Fri, May 18, 2012 at 04:32:09PM +0300, Alex Lyakas wrote:
>> Thank you, Hugo, for the detailed explanation. I am now able to fi
;
if (nritems == 0)
return 1;
if (path->slots[0] == nritems)
path->slots[0]--;
# What is the btrfs_dir_item::data_len value is used for? I saw it
appearing in XATTR_ITEM, but not in DIR_INDEX/DIR_ITEM
Thanks!
Alex.
son I should be aware of "ram_bytes" field?
The first dd created a 4k extent at offset 12k. How did we end up with
"nr 8192 ram 8192" and offset 4k?
The second dd added a 4k extent at 8k offset. But still EXTENT_DATA
has 4k offset.
So now we should have have twp 4k extents or one 8
Thanks, Liu, that clarifies.
Alex.
On Tue, May 22, 2012 at 4:42 AM, Liu Bo wrote:
> On 05/21/2012 06:05 PM, Alex Lyakas wrote:
>
>> Hi Liu,
>> thanks for the clarifications.
>>
>> I did not understand the dd example of yours, though.
>>
>>> So for th
ast slot has key=2.
If such tree is valid, then: btrfs_prev_leaf() will search for key==9.
Then btrfs_search_slot() would bring us node N and leaf A again,
wouldn't it? Because key(N)<=9. So we will receive leaf A back, and
will think that there is no previous leaf, while there is.
What
to
leaf A. While if key(N) of that slot was 10, we would never have ended
up in that slot, unless there is no lesser key in the tree. Actually,
it looks like "no lesser key" is the only case when we can get ret==1
and slot==0. Except perhaps an empty leaf, which I am not sure can
happen.
But I
Thank you Jan, Hugo & Lio,
for taking time answering my questions.
Alex.
P.S.: I have dug in some more, so probably more questions will arrive:)
On Tue, May 29, 2012 at 12:13 PM, Jan Schmidt wrote:
> On Mon, May 28, 2012 at 20:45 (+0200), Alex Lyakas wrote:
>> I have
Hi Jan, Alex,
I have seen some discussions about btrfs send/receive functionality
being developed by you. I have also been interested in this. I spent
some time coding a prototype doing something like Alex described in
http://www.spinics.net/lists/linux-btrfs/msg16175.html, i.e., walking
over FS
Hi Arne,
On Mon, Jun 4, 2012 at 4:01 PM, Arne Jansen wrote:
> On 04.06.2012 14:39, Alex Lyakas wrote:
>
>>
>> # How does one track changes in generic INODE_ITEM properties, like
>> "mode" or "uid/gid"? Whenever such property gets changed, INODE_ITEM
&
On Mon, Jun 4, 2012 at 6:33 PM, Alexander Block wrote:
> On Mon, Jun 4, 2012 at 5:10 PM, shyam btrfs wrote:
>> Hi Alex, Jan,
>>
>> I was also interested in send/receive semantics & was thinking that if
>> we adhere to the semantics as in
>> http://www.mail-ar
On Tue, Jun 5, 2012 at 12:16 PM, Alexander Block
wrote:
> On Mon, Jun 4, 2012 at 7:33 PM, Alex Lyakas
> wrote:
>>
>> Yes, I also noticed that sometimes transid gets bumped up, but there
>> is no actual change.
>>
>> So let's say you identify that a par
,
Alex.
On Sat, May 26, 2012 at 1:59 PM, Jan Schmidt wrote:
> Chris: Please pull
>
> git://git.jan-o-sch.net/btrfs-unstable for-chris
>
> for 3.5, it's a major improvement for the backref resolver and a good
> base to build qgroups and "btrfs send"
ed" and "received" blocks that
fio reports. I added one such file (job0.1.0.88576.now) to the
pastebin as well.
If you think that my fio configuration file is faulty, please let me
know. fio version is 1.59. The idea is to run 10 io processes in
parallel.
Thanks,
Alex.
-fio configu
+0x13/0x13
Thanks,
Alex.
On Mon, Jun 25, 2012 at 10:26 PM, Josef Bacik wrote:
> On Mon, Jun 25, 2012 at 12:30:34PM -0600, Alex Lyakas wrote:
>> Greetings everybody,
>>
>> I am running a fio test on btrfs compiled from
>> git://git.kernel.org/pub/scm/linux/kern
uld I pull updates from for btrfs-progs?
Thanks,
Alex.
On Tue, Jun 5, 2012 at 10:09 PM, Hugo Mills wrote:
> I've just pushed out a new integration branch to my git repo. This
> is purely bugfix patches -- there are no new features in this issue of
> the integration branch. I've
Thanks, Hugo.
At this point I mostly want to learn and stay up-to-date with new
patches coming in.
Alex.
On Tue, Jun 26, 2012 at 12:58 PM, Hugo Mills wrote:
> On Tue, Jun 26, 2012 at 11:58:41AM +0300, Alex Lyakas wrote:
>> Hi Hugo,
>> forgive me, but I am somewhat confused.
.01%
Run status group 0 (all jobs):
READ: io=21874MB, aggrb=1KB/s, minb=0KB/s, maxb=150KB/s,
mint=16416381msec, maxt=17694821418msec
WRITE: io=21873MB, aggrb=1KB/s, minb=0KB/s, maxb=151KB/s,
mint=16416264msec, maxt=17694821418msec
fio: file hash not empty on exit
Thanks,
Alex.
On Tue, Jun 26
itepages
remotes/origin/master1573317 Btrfs: use helper function to simplify code
Thanks,
Alex.
On Wed, Jun 27, 2012 at 4:46 PM, Josef Bacik wrote:
> On Wed, Jun 27, 2012 at 02:15:59AM -0600, Alex Lyakas wrote:
>> Hi Josef,
>> I have rerun the test with btrfs-next mast
ots
is not available.
Below is some information, pls let me know if any additional info is needed.
Thanks,
Alex.
The superblock structure:
$11 = {csum = "Ø\017\336", '\000' , fsid =
"??CC\330\344M\327\272\237\003\363\065\266\274", , bytenr = 65536, flags = 1, magic
I will try some more tests,
changing different components.
Alex.
Kernel log:
Jul 3 00:02:12 vsa-0018-vc-1 kernel: [ 9000.740135] INFO: task
df:3113 blocked for more than 120 seconds.
Jul 3 00:02:12 vsa-0018-vc-1 kernel: [ 9000.741878] "echo 0 >
/proc/sys/kernel/hung_task_timeout_s
Stephan,
Thank you for the analysis. Yes, I fully switched the dmsetup to
"error". Below are my kernel logs, in case you still need them.
Thanks,
Alex.
Jul 2 15:33:29 dev kernel: [ 267.979062] Btrfs loaded
Jul 2 15:34:18 dev kernel: [ 317.331859] device fsid
3f3f4343-d8e4
Hi Alex,
> + spin_lock(&left_root->root_times_lock);
> + ctransid = btrfs_root_ctransid(&left_root->root_item);
> + spin_unlock(&left_root->root_times_lock);
> + if
Hi Alex,
> +static int tree_compare_item(struct btrfs_root *left_root,
> +struct btrfs_path *left_path,
> +struct btrfs_path *right_path,
> +char *tmp_buf)
> +{
> + int cmp;
> +
ance_left = ADVANCE;
}
Note: I think that instead of comparing levels, we could always
compare keys and ADVANCE the lower key. (Because on ADVANCing we never
loose information, we just get closer to leafs, so we don't skip
anything.) But then there is less chance of optimization. Does this
make sense? So what you said that we can compare keys only on the same
level...we can always compare them, correct?
I will now study the rest of your patchset.
Thanks!
Alex.
--
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
On Thu, Jul 5, 2012 at 3:47 PM, Alexander Block wrote:
> On Thu, Jul 5, 2012 at 2:19 PM, Alex Lyakas
> wrote:
>> Alexander,
>>
>>>>> + if (advance_left && !left_end_reached) {
>>>>> + ret
se.
I will keep playing with your code & let you know what else I find.
Thanks!
Alex.
--
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
accomplish, and why it decides that extent is unchanged here:
key.offset = found_key.offset + right_len;
if (key.offset >= ekey->offset + left_len) {
ret = 1;
goto out;
}
Also: when searching for the next extent, should we use
btrfs_file_extent_num_bytes() or btrfs_file
ooks from the kernel code that
it is expected that child-qgroupid < parent-qgroupid. Is this correct?
If yes, who is enforcing this?
Thanks for your help,
Alex.
On Thu, Jul 12, 2012 at 12:43 PM, Jan Schmidt wrote:
> This is a new version of Arne's qgroup patches from last October. The
&
Arne,
thanks for your comments.
On Tue, Jul 17, 2012 at 10:25 PM, Arne Jansen wrote:
> On 07/17/2012 08:33 PM, Alex Lyakas wrote:
>> Jan,
>> I have studied to some extent the PDF and the code. I have some
>> questions; perhaps you can address them?
>>
>> 1) b
incremented in btrfs_find_free_ino(), but
smaller unused numbers are reused?
Also, I don't see anywhere BTRFS_BTREE_INODE_OBJECTID in the tree root
tree. So what is this "btree inode" that you mention?
Thanks,
Alex.
On Tue, Jul 10, 2012 at 2:28 PM, Liu Bo wrote:
> For btree inode,
On Wed, Jul 18, 2012 at 3:02 PM, Liu Bo wrote:
> On 07/18/2012 06:02 PM, Alex Lyakas wrote:
>
> More or less.
>
> As its name shows, a free space inode's data (you name it extents) consists of
> free space info, meanwhile, a free space inode is issued to a block group,
&
hem out-of-order if needed?). But I
am not yet sure where is the core place that should ensure this.
Thanks,
Alex.
--
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
= path_cat(r->full_subvol_path, lnk);
...
ret = link(full_path/*oldpath*/, full_link_path/*newpath*/);
...
free(full_link_path);
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More maj
ails because it has no INODE_REFs. So
@@ -3923,6 +4127,13 @@ static int changed_cb(struct btrfs_root *left_root,
int ret = 0;
struct send_ctx *sctx = ctx;
+ /* Ignore non-FS objects */
+ if (key->objectid == BTRFS_FREE_INO_OBJECTID ||
+ key->objectid == BTRFS_FREE_SPACE_OBJECTID)
+ return 0;
makes sense?
Thanks,
Alex.
--
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
kind
of oXXX-YY-Z file(s) in the top dir by accident, then they are the
same every time we recalculate the orhpan name, so we get the same
result every time. Does it make sense?
So did you mean to generate a uuid here, and save it somewhere
in-memory, and later look it up based on (ino,gen)? Or you m
Thanks!
So now:
A_PATH -> path -> full_path -> newpath
A_PATH_LINK -> lnk -> full_link_path -> oldpath
while I viewed it the other way around.
I guess it's not important what is left/right, old/new :) as long as
it's consistent.
Alex.
On Tue, Jul 24, 2012 at 11:2
Alexander,
can you pls let know like a day or two before you run out of time?
I have compiled a list of questions, but also want to do more testing
before I publish them all.
Thanks for your work,
Alex.
On Wed, Jul 25, 2012 at 7:56 PM, Alexander Block
wrote:
> On Wed, Jul 25, 2012 at 4:00
nt had
some real data extent in that place? I don't know the answer, but if
yes, then we must treat PREALLOC as normal extent. So this case is
similar to bytenr==0.
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message
, p);
+ else
+ ret = get_cur_path(sctx, ino, gen, p, 0/*do_print*/);
if (ret < 0)
goto out;
I will continue testing more complicated cases now.
Thanks,
Alex.
On Tue, Jul 24, 2012 at 11:26 PM, Alexander Block
wrote:
> On Wed, Jul 18, 2012 at 7:45
en_unique_name(sctx, ino, gen, p);
} else {
ret = get_cur_path(sctx, ino, gen, p);
}
All of them except utimes() are used with cur_ino only, so for those
this check is redundant (and probably makes sense to drop ino/gen
parameters of them?).
Thanks,
Alex.
On Thu, Ju
;
if (ret < 0)
goto out;
btrfs_test_2.sh
The last test exposes an interesting issue: when a directory has a
deleted reference recorded, this deleted reference is not added to the
'check_dirs' list. As a result, the upper directory (already
orphanized) is n
Alexander,
yes, I will re-test and let you know. Expect to hear from me this week.
Do you plan to merge this "for-alex" branch into some "mainline"
branch, before you take off?
Thanks,
Alex.
On Sat, Jul 28, 2012 at 12:56 PM, Alexander Block
wrote:
> On Fri, Jul 27, 2012
anized) is not rmdir'd.
> You'll find a commit in my repo to fix this. The problem was, that
> moved directories do not get into the delete_refs loop and thus the
> parent of the old location is never added to the check_dirs list.
> I have force pushed to for-alex, if you have t
uot; field that you
mimic in generation_v2 and "ctransid"? (I know I need to study the
root tree code).
Thank you,
Alex.
--
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
Just realized I messed up sending this to the list.
Roman Mamedov wrote:
> On Mon, 30 Jul 2012 23:26:42 -0400 (EDT)
> serial...@lavabit.com wrote:
>
>> 1) is there a tool to help me recover data from my fs? I don't have a
>> backup of my partition table and so I have about 500GB of space where a
Alex Elsayed wrote:
> offset 0x10040 (64K + 64 bytes) there's the string BHRfS (hex 5F 42 48 52
> 66 53 5f). That matches the documentation (the first superblock should be
Ugh, and resending it stripped the underscores. _BHRfS_ is at 0x10040, not
BHRfS (which would be at 0x10
In using btrfs-restore, I've found that much of the time the interface is a
poor match for what I'm trying to do. It works fine in the simplest cases
where you want to extract everything, but wanting to extract a subset of the
files in a directory is more difficult, and it gets more complicated
the
>> root tree code).
> Did you read the comments for btrfs_root_item and
> btrfs_read_root_item? They should answer your question.
Yes, I read the comments, but they address only "generation" and
"generation_v2", which I understand. Basically, I don't understa
detailed) as your snapshot-diff tool.
Apologies if I somehow misunderstood what your snapshot-diff code does.
Thanks,
Alex.
On Tue, Aug 7, 2012 at 11:56 AM, Jeff Liu wrote:
> Hello,
>
> I've done a prototype implementation of snapshot diff utility many months ago.
> It was or
lesystem
(the one you are trying to backup), and where each one is mounted?
Again, looks like I'm the only one confused about this, so apologies.
You can also possibly use the "tree" utility to better visualize your
fs tree, like:
tree -A --inodes --noreport /mnt/TEST_ROOT
Jan,
end more data than
btrfs_file_extent_inline_len() indicates? I assume this code is
intended to handle "hole between the end of the inline item and the
start of the full extent", in which case it will read-and-send zeros
up to the start of the next extent. But why it is bad just to use the
o
Thank you, Robert for the detailed data. I will debug & get back to
you before Friday.
Alex.
On Mon, Aug 27, 2012 at 9:37 PM, Robert Buhren wrote:
> Hi Alex,
>
> i've made a list of all commands i executed for this test. You can find it
> here:
>
> http://pasteb
Hi Robert,
can you pls apply this patch. It should solve the issue (your script
now runs ok for me).
Alex.
diff --git a/cmds-receive.c b/cmds-receive.c
index a8be6fa..3ee2ff8 100644
--- a/cmds-receive.c
+++ b/cmds-receive.c
@@ -792,11 +792,18 @@ int do_receive(struct btrfs_receive *r, const
the output of btrfs-debug-tree.
Alex.
On Sun, Sep 9, 2012 at 3:30 AM, Jan Steffens wrote:
> On Sun, Sep 9, 2012 at 2:03 AM, ching wrote:
>> 2. Is there any command for the fragmentation status of a file/dir ? e.g.
>> fragment size, number of fragments.
>
> Use the &qu
to know whether community believes this issue is
worth to fix.
Thanks!
Alex.
--
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
Hi Jan,
I hope to get my proposal working soon, then expect for some code from
me to look at.
Thanks!
Alex.
On Mon, Sep 24, 2012 at 11:27 AM, Jan Schmidt wrote:
> Hi Alex,
>
> On Mon, September 24, 2012 at 11:13 (+0200), Alex Lyakas wrote:
>> Hi,
>>
>>> write_buf
there unless its first key has the same objectid. (I
think you use the ctree property that the key in the first node/leaf
of a tree block is equal to its parent's key).
Can you pls explain why you insist on the same objectid?
Thanks,
Alex.
On Mon, Sep 24, 2012 at 10:02 PM, Josef Bacik
at's why I was somewhat
puzzled by your change. If you decide to keep your change, can you pls
update the comment of btrfs_next_leaf()/next_old_leaf().
Thanks again,
Alex.
On Mon, Oct 1, 2012 at 6:45 PM, Josef Bacik wrote:
> On Sun, Sep 30, 2012 at 05:28:23AM -0600, Alex Lyakas wrote:
our change it might get broken... What do
you think?
Thanks,
Alex.
On Tue, Oct 2, 2012 at 5:30 PM, Arne Jansen wrote:
> On 02.10.2012 17:27, Josef Bacik wrote:
>> On Tue, Oct 02, 2012 at 09:05:43AM -0600, David Sterba wrote:
>>> On Tue, Oct 02, 2012 at 10:32:32AM -0400, Josef Bac
ee(longest_match);
> + longest_matchlen = len;
> + longest_match = strdup(ent->mnt_dir);
Alex.
--
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
th IOCTLs, and is based on a different Chris's
branch (but has latest send-recv code).
Thanks for taking time reading up to here (hopefully). I appreciate
any comments on the code.
Alex.
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
old mode 100644
new mode 100755
index fcc8c21..4e1049a
Matrin,
On Sat, Oct 6, 2012 at 11:40 AM, Martin Steigerwald wrote:
> Am Donnerstag, 4. Oktober 2012 schrieb Alex Lyakas:
>> Hi Jan,
>> as I promised, here is some code for you to look at.
>>
>> First I will describe the approach in general.
>>
>> # Get rid
handles them. After it is
done with the buffer, it puts it back on a free-buffer queue and
signals the first thread. This is exactly producer-consumer.
Alex.
On Sun, Oct 7, 2012 at 12:53 PM, Martin Steigerwald wrote:
> Am Sonntag, 7. Oktober 2012 schrieb Alex Lyakas:
>> Matrin,
>
&
Hi Jan,
thanks for taking time to look at the code.
On Mon, Oct 8, 2012 at 11:26 AM, Jan Schmidt wrote:
> Hi Alex,
>
> On Thu, October 04, 2012 at 17:59 (+0200), Alex Lyakas wrote:
>> as I promised, here is some code for you to look at.
>
> And quite a lot of it. I hadn&#x
s patch both Rory's tests seem to
work for me.
Thanks,
Alex.
diff --git a/cmds-receive.c b/cmds-receive.c
index a8be6fa..ed53326 100644
--- a/cmds-receive.c
+++ b/cmds-receive.c
@@ -52,11 +52,13 @@ static int g_verbose = 0;
struct btrfs_receive
{
int mnt_fd;
+ int dest
Hi Jan,
On Mon, Oct 8, 2012 at 3:37 PM, Jan Schmidt wrote:
> On Mon, October 08, 2012 at 13:38 (+0200), Alex Lyakas wrote:
>>>> I realize this is a big change, and a new IOCTL has to be introduced
>>>> in order not to break current user-kernel protocol.
>>>
is mounted (it can also be the same as
the mount point, but not above it). Does this make sense?
Also it should not matter where the sent subvolume resided in the
source fs, and, if this is a diff-send, where you have received the
parent snapshot to (as long as it is on/under the same mount point)
REF_KEY;
> + continue;
> + }
And here.
> if (ret)
> break;
>
> @@ -3987,7 +4027,7 @@ static int process_recorded_refs_if_needed(struct
> send_ctx *sctx, int at_end)
> if (sctx->cur_ino == 0)
inodes --noreport -s /mnt
before you start the test (I assume that two subvolumes at /mnt are
empty, right).
However, I doubt the contents will really help, because it seems to
fail very early, even before it starts processing the commands.
Thanks,
Alex.
On Thu, Oct 11, 2012 at 1:33 PM, Rory Campb
101 - 200 of 377 matches
Mail list logo
