From: email@example.com To: Remi Gauvin <firstname.lastname@example.org> Cc: linux-btrfs <email@example.com> Subject: Re: Feature requests: online backup - defrag - change RAID level Date: Wed, 11 Sep 2019 23:05:42 -0400 Message-ID: <20190911230542.Horde.UywNUEBF6L2ExMalgJ0dDTG@server53.web-hosting.com> (raw) In-Reply-To: <firstname.lastname@example.org> Quoting Remi Gauvin <email@example.com>: > On 2019-09-11 7:21 p.m., firstname.lastname@example.org wrote: > >> For example, lets examine the typical home user. If he is using btrfs, >> it means he probably wants snapshots of his data. And, after a few >> snapshots, his data is fragmented, and the current defrag can't help >> because it does a terrible job in this particualr case. >> > > I shouldn't be replying to your provocative posts, but this is just > nonsense. I really hope that I'm not such a bad person as that sentence is suggesting. About the provocative posts, I don't know of any other way to get my thoughts across. If I offended people, I appologize, but I cannot change the way I communicate. Certainly, I like the btrfs filesystem and the features it offers, and I'll continue using it, and no matter what you think of me I want to say thanks to you guys who are making it all work. > Not to say that Defragmentation can't be better, smarter,, it happens > to work very well for typical use. My thought is that the only reason why it appears that it works is that a typical home user rarely needs defragmentation. He runs the "btrfs fi defrag", virtually nothing happens (a few log files get defragged, if they were shared than they are unshared), prints out "Done", the user is happy. Placebo effect. > This sounds like you're implying that snapshots fragment data... can you > explain that? as far as I know, snapshotting has nothing to do with > fragmentation of data. All data is COW, and all files that are subject > to random read write will be fragmented, with or without snapshots. Close, but essentially: yes. I'm implying that snapshots induce future fragmentation. The mere act of snapshoting won't create fragments immediately, but if there are any future writes to previously snapshoted files, those writes are likely to cause fragmentation. I think that this is not hard to figure out, but if you wish, I can elaborate further. The real question is: does it really matter? Looking at the typical home user, most of his files rarely change, they are rarely written to. More likely, most new writes will go to new files. So, maybe the "home user" is not the best study-case for defragmentation. He has to be at least some kind of power-user, or content-creator to experience any significant fragmentation. > And running defrag on your system regularly works just fine. There's a > little overhead of space if you are taking regular snapshots, (say > hourly snapshots with snapper.) If you have more control/liberty when > you take your snapshots, ideally, you would defrag before taking the > snaptshop/reflink copy. Again, this only matters to files that are > subject to fragmentation in the first place. Btrfs defrag works just fine until you get some serious fragmentation. At that point, if you happen to have some snapshots, you better delete them before running defrag. Because, if you do run defrag on snapshoted and heavily fragmented filesystem, you are going to run out of disk space really fast. > I suspect if you actually tried using the btrfs defrag, you would find > you are making a mountain of a molehill.. There are lots of far more > important problems to solve. About importance, well, maybe you are right there, maybe not. Somehow I guess that after so many years in development and a stable feature set, most remaining problems are bugs and trivialities. So you are fixing them, one by one, many of those are urgent. I see you are working on deduplication, that's a hell of a work which actually won't end up well if it is not supplemented by a good defrag. Didn't someone say, earlier in this discussion, that the defrag is important for btrfs. I would guess that it is. On many OSes defrag is run automatically. All older filesystems have a pretty good defrag. What I would say is that btrfs can have a much better defrag than it has now. If defrag is deemed important, thay why are improvements to defrag unimportant?
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 [this message] 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 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 \ --in-reply-to=20190911230542.Horde.UywNUEBF6L2ExMalgJ0dDTG@server53.web-hosting.com \ --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