From: Zygo Blaxell <email@example.com> To: General Zed <firstname.lastname@example.org> Cc: email@example.com Subject: Re: Feature requests: online backup - defrag - change RAID level Date: Wed, 18 Sep 2019 14:00:49 -0400 Message-ID: <20190918180049.GI24379@hungrycats.org> (raw) In-Reply-To: <20190918003742.Horde.uCadf9qXuYdCVqBfASzDeuN@server53.web-hosting.com> On Wed, Sep 18, 2019 at 12:37:42AM -0400, General Zed wrote: > It just postpones the inevitable, but you missed the point. The point of > shutting down dedupe is to avoid nasty bugs caused by dedupe-defrag > interaction. They are the same bugs you'll have to fix anyway. Dedupe isn't particularly special or different from the way that other btrfs write operations work, and nobody wants to be locked out of their filesystem during a big data relocation operation. Even balance doesn't prevent concurrent filesystem modification--it allows concurrent changes, and restarts processing to take care of them when necessary. > The share-preserving defrag shouldn't interfere with dedupe because defrag > is run on-demand, and it should then shut down dedupe until it has > completed. Therefore, the issues it causes to dedupe are only temporary (and > minor, really). On big filesystems fragmentation is a _continuous_ problem that gets more expensive to fix the longer it is neglected. So I'd naturally expect both dedupe and defrag agents to be active at the same time, or very closely interleaved, with concurrent data updates as well. VM images and database files are hotspots for all three activities. I'd expect a sysadmin interface more like balance, where the interface looks like "run defrag now, relocating at most 20GB of data" and defrag decides (possibly with hints from the admin) which 20GB of data out of 50TB of filesystem that should be. Or I'd set the defrag limit to 1GB per run, and run it as many times as possible in a maintenance window until either the time runs out or defrag says "no further optimization is practical or possible, you can stop looping now." For small systems it doesn't matter--admin says "relocate at most 1TB of data" and new-and-improved defrag says "easy, that's the whole filesystem." But small systems are not very interesting. On small systems I can just run the current reflink-breaking file-oriented recursive defrag and dedupe at the same time. Dedupe can put the sharing back almost as fast as current reflink-breaking defrag can break it, the whole thing finishes in minutes, and I don't even bother calculating how many iops were wasted because they were all free. > > I guess the extent-merge call could be augmented with an address hint > > for allocation, but experiments so far have indicated that the possible > > gains are marginal at best given the current btrfs allocator behaviour, > > so I haven't bothered pursuing that. > > The "batch-update" from defrag should certainly trumps any "extent-merge". > The defrag will do it all for you, you just supply the defrag with a list of > extents that need to be defragmented. Sure...either way, it's an ioctl that takes a list of extents to be defragmented as an argument, and produces an output locally optimized for minimal fragmentation, updating and removing references to the old locations, etc. Maybe it's a single list input and single extent output; maybe it's a list of lists which produces multiple extent outputs; maybe you can call it multiple times per commit and the kernel batches them up when it does a flush; maybe it takes allocation hints in the argument because the user already knows the best free space location; maybe it finds its own contiguous space; maybe you pass it a file descriptor and offset to a O_TMPFILE file where you already allocated the destination area with fallocate; maybe there's two separate ioctls, one sets up the destination area and the other moves extent data into it. You can call that ioctl(s) 'batch-update' or 'extent-merge' or whatever you like. Figure out the requirements and make a proposal, we can see where the proposals overlap or decompose them into common components. Other questions you've asked indicate you are thinking of doing the bulk of the defrag work in the kernel. This is not a good idea. It's hard to allocate and effectively use large amounts of memory in the kernel (for developers and users alike), and the in-kernel btrfs maintenance tools so far have proven to make desirable administrative functions like IO bandwidth management difficult to impossible. Once code is integrated into the kernel, it has to be kept around more or less forever, even if it is half-finished, obviously awful, and nobody can use it seriously without major redesign. The current defrag ioctl is a prime example of that, but balance and send are also good examples of things that would have been better outside the kernel if the right interfaces had been available at the time they were designed. (Balance could also be implemented in userspace with a batch-update data relocation ioctl, and could easily avoid several problems with the current kernel implementation in the process.) It's much easier to do big-memory operations in userspace (not just the technical operations themselves, but also getting the code accepted in the kernel). There are already interfaces for rapid ingestion of the necessary metadata from userspace, so defrag's needs are covered there. What is currently missing is good kernel interfaces for rapid implementation of the output of data relocation algorithms (i.e. ioctls to move extent data precisely as instructed and don't break references). Leave the kernel to physically move the data and update metadata once userspace knows where it should go, but don't make the kernel try to plan stuff or make decisions on its own--that doesn't end well. Minimizing the kernel code footprint will also make it much easier to avoid crashes and deadlocks (or at least make them harmless should they occur). btrfs has had more deadlock bugs than any two other filesystems on Linux combined, so designs that minimize the risk of adding new deadlocks will be preferred. I don't think you can gain much by throwing kernel memory at predetermining extent moves, given the current on-disk structure of btrfs. Existing sharing-preserving extent move operations in btrfs are currently dominated by _read_ IO times--the writes are fast mostly-contiguous flushes, while the reads are slow random accesses. The kernel already caches reads well already, there are just a lot of them to do when doing anything related to extent backrefs. On small filesystems the whole metadata fits comfortably in 10% of RAM (below default page cache eviction thresholds), and on filesystems of that size you can already do full balances in minutes, there is no problem to be solved there. You can prefetch metadata into cache RAM by running TREE_SEARCH_V2 on it, if you think that will help. Consider the XFS kernel interfaces for defrag. It may be possible to implement those on btrfs, then make minor modifications to xfs_fsr so it can do defrag on btrfs (probably not efficiently--xfs_fsr likely assumes extent splits are possible without moving data--but it's a good example of a kernel interface designed for defrag nonetheless).
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 [this message] 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 publically 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=20190918180049.GI24379@hungrycats.org \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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 \ email@example.com 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