On Fri, May 18, 2018 at 04:26:16PM -0600, Chris Murphy wrote: > On Fri, May 18, 2018 at 12:33 PM, Austin S. Hemmelgarn > <ahferroin7@xxxxxxxxx> wrote: > > On 2018-05-18 13:18, Niccolò Belli wrote: > >> > >> On venerdì 18 maggio 2018 19:10:02 CEST, Austin S. Hemmelgarn wrote: > >>> > >>> and also forces the people who have ridiculous numbers of snapshots to > >>> deal with the memory usage or never defrag > >> > >> > >> Whoever has at least one snapshot is never going to defrag anyway, unless > >> he is willing to double the used space. > >> > > With a bit of work, it's possible to handle things sanely. You can > > deduplicate data from snapshots, even if they are read-only (you need to > > pass the `-A` option to duperemove and run it as root), so it's perfectly > > reasonable to only defrag the main subvolume, and then deduplicate the > > snapshots against that (so that they end up all being reflinks to the main > > subvolume). Of course, this won't work if you're short on space, but if > > you're dealing with snapshots, you should have enough space that this will > > work (because even without defrag, it's fully possible for something to > > cause the snapshots to suddenly take up a lot more space). > > > Curiously, snapshot aware defragmentation is going to increase free > space fragmentation. For busy in-use systems, it might be necessary to > use space cache v2 to avoid performance problems. > > I forget the exact reason why the free space tree is not the default, > I think it has to do with missing repair support? Yeah, Nikolay is working on that. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
