On 2019/9/9 上午10:55, zedlr...@server53.web-hosting.com wrote: > Hello everyone! > [...] > > 1) Full online backup (or copy, whatever you want to call it) > btrfs backup <filesystem name> <partition name> [-f] > - backups a btrfs filesystem given by <filesystem name> to a partition > <partition name> (with all subvolumes).
Why not just btrfs send? Or you want to keep the whole subvolume structures/layout? > > - To be performed by creating a new btrfs filesystem in the destination > partition <partition name>, with a new GUID. I'd say current send/receive is more flex. And you also needs to understand btrfs also integrates volume management, thus it's not just <partition name>, you also needs RAID level and things like that. > - All data from the source filesystem <filesystem name> is than copied > to the destination partition, similar to how RAID1 works. > - The size of the destination partition must be sufficient to hold the > used data from the source filesystem, otherwise the operation fails. The > point is that the destination doesn't have to be as large as source, > just sufficient to hold the data (of course, many details and concerns > are skipped in this short proposal) All can be done already by send/receive, although at subvolume level. Please check if send/receive is suitable for your use case. [...] > > 2) Sensible defrag > The defrag is currently a joke. If you use defrag than you better not > use subvolumes/snapshots. That's... very… hard to tolerate. Quite a > necessary feature. I mean, defrag is an operation that should be > performed in many circumstances, and in many cases it is even > automatically initiated. But, btrfs defrag is virtually unusable. And, > it is unusable where it is most needed, as the presence of subvolumes > will, predictably, increase fragmentation by quite a lot. > > How to do it: > - The extents must not be unshared, but just shuffled a bit. Unsharing > the extents is, in most situations, not tolerable. I definitely see cases unsharing extents makes sense, so at least we should let user to determine what they want. > > - The defrag should work by doing a full defrag of one 'selected > subvolume' (which can be selected by user, or it can be guessed because > the user probably wants to defrag the currently mounted subvolume, or > default subvolume). The other subvolumes should than share data (shared > extents) with the 'selected subvolume' (as much as possible). What's wrong with current file based defrag? If you want to defrag a subvolume, just iterate through all files. > > - I think it would be wrong to use a general deduplication algorithm for > this. Instead, the information about the shared extents should be > analyzed given the starting state of the filesystem, and than the > algorithm should produce an optimal solution based on the currently > shared extents. Please be more specific, like giving an example for it. > > Deduplication is a different task. > > 3) Downgrade to 'single' or 'DUP' (also, general easy way to switch > between RAID levels) > > Currently, as much as I gather, user has to do a "btrfs balance start > -dconvert=single -mconvert=single > ", than delete a drive, which is a bit ridiculous sequence of operations. > > Can you do something like "btrfs delete", but such that it also > simultaneously converts to 'single', or some other chosen RAID level? That's a shortcut for chunk profile change. My first idea of this is, it could cause more problem than benefit. (It only benefits profile downgrade, thus only makes sense for RAID1->SINGLE, DUP->SINGLE, and RAID10->RAID0, nothing else) I still prefer the safer allocate-new-chunk way to convert chunks, even at a cost of extra IO. Thanks, Qu > > ## I hope that you will consider my suggestions, I hope that I'm helpful > (although, I guess, the short time I spent working with btrfs and > writing this mail can not compare with the amount of work you are > putting into it). Perhaps, teams sometimes need a different perspective, > outsiders perspective, in order to better understand the situation. > > So long! >
signature.asc
Description: OpenPGP digital signature
