From: Nikolay Borisov <firstname.lastname@example.org> To: email@example.com Cc: firstname.lastname@example.org Subject: Re: Feature requests: online backup - defrag - change RAID level Date: Wed, 11 Sep 2019 09:40:52 +0300 Message-ID: <email@example.com> (raw) In-Reply-To: <20190910183546.Horde.QoJ4NOAAxdCw46gLRejnHRv@server53.web-hosting.com> On 11.09.19 г. 1:35 ч., firstname.lastname@example.org wrote: > > Quoting Nikolay Borisov <email@example.com>: > > >>>> >>>> You're exactly in the pitfall of btrfs backref walk. >>>> >>>> For btrfs, it's definitely not an easy work to do backref walk. >>>> btrfs uses hidden backref, that means, under most case, one extent >>>> shared by 1000 snapshots, in extent tree (shows the backref) it can >>>> completely be possible to only have one ref, for the initial subvolume. >>>> >>>> For btrfs, you need to walk up the tree to find how it's shared. >>>> >>>> It has to be done like that, that's why we call it backref-*walk*. >>>> >>>> E.g >>>> A (subvol 257) B (Subvol 258, snapshot of 257) >>>> | \ / | >>>> | X | >>>> | / \ | >>>> C D >>>> / \ / \ >>>> E F G H >>>> >>>> In extent tree, E is only referred by subvol 257. >>>> While C has two referencers, 257 and 258. >>>> >>>> So in reality, you need to: >>>> 1) Do a tree search from subvol 257 >>>> You got a path, E -> C -> A >>>> 2) Check each node to see if it's shared. >>>> E is only referred by C, no extra referencer. >>>> C is refered by two new tree blocks, A and B. >>>> A is refered by subvol 257. >>>> B is refered by subvol 258. >>>> So E is shared by 257 and 258. >>>> >>>> Now, you see how things would go mad, for each extent you must go that >>>> way to determine the real owner of each extent, not to mention we can >>>> have at most 8 levels, tree blocks at level 0~7 can all be shared. >>>> >>>> If it's shared by 1000 subvolumes, hope you had a good day then. >>> >>> Ok, let's do just this issue for the time being. One issue at a time. It >>> will be easier. >>> >>> The solution is to temporarily create a copy of the entire backref-tree >>> in memory. To create this copy, you just do a preorder depth-first >>> traversal following only forward references. >>> >>> So this preorder depth-first traversal would visit the nodes in the >>> following order: >>> A,C,E,F,D,G,H,B >>> >>> Oh, it is not a tree, it is a DAG in that example of yours. OK, preorder >>> is possible on DAG, too. But how did you get a DAG, shouldn't it be all >>> trees? >>> >>> When you have the entire backref-tree (backref-DAG?) in memory, doing a >>> backref-walk is a piece of cake. >>> >>> Of course, this in-memory backref tree has to be kept in sync with the >>> filesystem, that is it has to be updated whenever there is a write to >>> disk. That's not so hard. >> >> Great, now that you have devised a solution and have plenty of >> experience writing code why not try and contribute to btrfs? > > First, that is what I'm just doing. I'm contributing to discussion on > most needed features of btrfs. I'm helping you to get on the right track "most needed" according to your needs. Again, "right track" according to you. > and waste less time on unimportant stuff. Who decides whether something is important or unimportant? > > You might appreciate my help, or not, but I am trying to help. > > What you probaby wanted to say is that you would like me to contribute > by writing code, pro bono. Unfortunately, I work for money as does the > 99% of the population. Why not contribute for free? For the same reason > why the rest of the population doesn't work for free. And, I'm not going > from door to door and buggin everyone with "why don't you work for > free", "why don't you help this noble cause..." blah. Makes no sense to me. Correct, this boils down there are essentially 2 ways to get something done in open source - code or money. So far you haven't provided either. By the same token - why should anyone do, in essence, pro-bono work for features *you* are specifically interested? Let's not kid ourselves - that's what this is all about. So while the discussion you spurred could be somewhat beneficial the style you use is definitely not. It's, at the very least, grating and somewhat aggressive. You haven't done any technical work on btrfs yet when more knowledgeable people, who have spent years(!!!) working on the code base tell you that there are technical reasons why things are the way they are you are brisk to dismiss their opinion. Of course they might very well be wrong - prove it to them, ideally with code. Given this how do you expect people to be interested in engaging in a meaningful conversation with you?
next prev parent reply index Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-09 2:55 zedlryqc 2019-09-09 3:51 ` Qu Wenruo 2019-09-09 11:25 ` zedlryqc 2019-09-09 12:18 ` Qu Wenruo 2019-09-09 12:28 ` Qu Wenruo 2019-09-09 17:11 ` webmaster 2019-09-10 17:39 ` Andrei Borzenkov 2019-09-10 22:41 ` webmaster 2019-09-09 15:29 ` Graham Cobb 2019-09-09 17:24 ` Remi Gauvin 2019-09-09 19:26 ` webmaster 2019-09-10 19:22 ` Austin S. Hemmelgarn 2019-09-10 23:32 ` webmaster 2019-09-11 12:02 ` Austin S. Hemmelgarn 2019-09-11 16:26 ` Zygo Blaxell 2019-09-11 17:20 ` webmaster 2019-09-11 18:19 ` Austin S. Hemmelgarn 2019-09-11 20:01 ` webmaster 2019-09-11 21:42 ` Zygo Blaxell 2019-09-13 1:33 ` General Zed 2019-09-11 21:37 ` webmaster 2019-09-12 11:31 ` Austin S. Hemmelgarn 2019-09-12 19:18 ` webmaster 2019-09-12 19:44 ` Chris Murphy 2019-09-12 21:34 ` General Zed 2019-09-12 22:28 ` Chris Murphy 2019-09-12 22:57 ` General Zed 2019-09-12 23:54 ` Zygo Blaxell 2019-09-13 0:26 ` General Zed 2019-09-13 3:12 ` Zygo Blaxell 2019-09-13 5:05 ` General Zed 2019-09-14 0:56 ` Zygo Blaxell 2019-09-14 1:50 ` General Zed 2019-09-14 4:42 ` Zygo Blaxell 2019-09-14 4:53 ` Zygo Blaxell 2019-09-15 17:54 ` General Zed 2019-09-16 22:51 ` Zygo Blaxell 2019-09-17 1:03 ` General Zed 2019-09-17 1:34 ` General Zed 2019-09-17 1:44 ` Chris Murphy 2019-09-17 4:55 ` Zygo Blaxell 2019-09-17 4:19 ` Zygo Blaxell 2019-09-17 3:10 ` General Zed 2019-09-17 4:05 ` General Zed 2019-09-14 1:56 ` General Zed 2019-09-13 5:22 ` General Zed 2019-09-13 6:16 ` General Zed 2019-09-13 6:58 ` General Zed 2019-09-13 9:25 ` General Zed 2019-09-13 17:02 ` General Zed 2019-09-14 0:59 ` Zygo Blaxell 2019-09-14 1:28 ` General Zed 2019-09-14 4:28 ` Zygo Blaxell 2019-09-15 18:05 ` General Zed 2019-09-16 23:05 ` Zygo Blaxell 2019-09-13 7:51 ` General Zed 2019-09-13 11:04 ` Austin S. Hemmelgarn 2019-09-13 20:43 ` Zygo Blaxell 2019-09-14 0:20 ` General Zed 2019-09-14 18:29 ` Chris Murphy 2019-09-14 23:39 ` Zygo Blaxell 2019-09-13 11:09 ` Austin S. Hemmelgarn 2019-09-13 17:20 ` General Zed 2019-09-13 18:20 ` General Zed 2019-09-12 19:54 ` Austin S. Hemmelgarn 2019-09-12 22:21 ` General Zed 2019-09-13 11:53 ` Austin S. Hemmelgarn 2019-09-13 16:54 ` General Zed 2019-09-13 18:29 ` Austin S. Hemmelgarn 2019-09-13 19:40 ` General Zed 2019-09-14 15:10 ` Jukka Larja 2019-09-12 22:47 ` General Zed 2019-09-11 21:37 ` Zygo Blaxell 2019-09-11 23:21 ` webmaster 2019-09-12 0:10 ` Remi Gauvin 2019-09-12 3:05 ` webmaster 2019-09-12 3:30 ` Remi Gauvin 2019-09-12 3:33 ` Remi Gauvin 2019-09-12 5:19 ` Zygo Blaxell 2019-09-12 21:23 ` General Zed 2019-09-14 4:12 ` Zygo Blaxell 2019-09-16 11:42 ` General Zed 2019-09-17 0:49 ` Zygo Blaxell 2019-09-17 2:30 ` General Zed 2019-09-17 5:30 ` Zygo Blaxell 2019-09-17 10:07 ` General Zed 2019-09-17 23:40 ` Zygo Blaxell 2019-09-18 4:37 ` General Zed 2019-09-18 18:00 ` Zygo Blaxell 2019-09-10 23:58 ` webmaster 2019-09-09 23:24 ` Qu Wenruo 2019-09-09 23:25 ` webmaster 2019-09-09 16:38 ` webmaster 2019-09-09 23:44 ` Qu Wenruo 2019-09-10 0:00 ` Chris Murphy 2019-09-10 0:51 ` Qu Wenruo 2019-09-10 0:06 ` webmaster 2019-09-10 0:48 ` Qu Wenruo 2019-09-10 1:24 ` webmaster 2019-09-10 1:48 ` Qu Wenruo 2019-09-10 3:32 ` webmaster 2019-09-10 14:14 ` Nikolay Borisov 2019-09-10 22:35 ` webmaster 2019-09-11 6:40 ` Nikolay Borisov [this message] 2019-09-10 22:48 ` webmaster 2019-09-10 23:14 ` webmaster 2019-09-11 0:26 ` webmaster 2019-09-11 0:36 ` webmaster 2019-09-11 1:00 ` webmaster 2019-09-10 11:12 ` Austin S. Hemmelgarn 2019-09-09 3:12 webmaster
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-BTRFS Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \ firstname.lastname@example.org public-inbox-index linux-btrfs Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs AGPL code for this site: git clone https://public-inbox.org/public-inbox.git