03.07.2018 10:15, Duncan пишет: > Andrei Borzenkov posted on Tue, 03 Jul 2018 07:25:14 +0300 as excerpted: > >> 02.07.2018 21:35, Austin S. Hemmelgarn пишет: >>> them (trimming blocks on BTRFS gets rid of old root trees, so it's a >>> bit dangerous to do it while writes are happening). >> >> Could you please elaborate? Do you mean btrfs can trim data before new >> writes are actually committed to disk? > > No. > > But normally old roots aren't rewritten for some time simply due to odds > (fuller filesystems will of course recycle them sooner), and the btrfs > mount option usebackuproot (formerly recovery, until the norecovery mount > option that parallels that of other filesystems was added and this option > was renamed to avoid confusion) can be used to try an older root if the > current root is too damaged to successfully mount. > > But other than simply by odds not using them again immediately, btrfs has > no special protection for those old roots, and trim/discard will recover > them to hardware-unused as it does any other unused space, tho whether it > simply marks them for later processing or actually processes them > immediately is up to the individual implementation -- some do it > immediately, killing all chances at using the backup root because it's > already zeroed out, some don't. >
How is it relevant to "while writes are happening"? Will trimming old tress immediately after writes have stopped be any different? Why? > In the context of the discard mount option, that can mean there's never > any old roots available ever, as they've already been cleaned up by the > hardware due to the discard option telling the hardware to do it. > > But even not using that mount option, and simply doing the trims > periodically, as done weekly by for instance the systemd fstrim timer and > service units, or done manually if you prefer, obviously potentially > wipes the old roots at that point. If the system's effectively idle at > the time, not much risk as the current commit is likely to represent a > filesystem in full stasis, but if there's lots of writes going on at that > moment *AND* the system happens to crash at just the wrong time, before > additional commits have recreated at least a bit of root history, again, > you'll potentially be left without any old roots for the usebackuproot > mount option to try to fall back to, should it actually be necessary. > Sorry? You are just saying that "previous state can be discarded before new state is committed", just more verbosely. -- 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
