On 2016-08-15 10:06, Daniel Caillibaud wrote:
Le 15/08/16 à 08:32, "Austin S. Hemmelgarn" <ahferroin7@xxxxxxxxx> a écrit :
ASH> On 2016-08-15 06:39, Daniel Caillibaud wrote:
ASH> > I'm newbie with btrfs, and I have pb with high load after each btrfs subvolume delete
[…]
ASH> Before I start explaining possible solutions, it helps to explain what's
ASH> actually happening here.
[…]
Thanks a lot for these clear and detailed explanations.
Glad I could help.
ASH> > Is there a better way to do so ?
ASH> While there isn't any way I know of to do so, there are ways you can
ASH> reduce the impact by reducing how much your backing up:
Thanks for these clues too !
I'll use --commit-after, in order to wait for complete deletion before starting rsync the next
snapshot, and I keep in mind the benefit of putting /var/log outside the main subvolume of the
vm (but I guess my main pb is about databases, because their datadir are the ones with most
writes).
With respect to databases, you might consider backing them up separately
too. In many cases for something like an SQL database, it's a lot more
flexible to have a dump of the database as a backup than it is to have
the database files themselves, because it decouples it from the
filesystem level layout. Most good databases should be able to give you
a stable dump (assuming of course that the application using the
databases is sanely written) a whole lot faster than you could back up
the files themselves. For the couple of databases we use internally
where I work, we actually back them up separately not only to retain
this flexibility, but also because we have them on a separate backup
schedule from the rest of the systems because they change a lot more
frequently than anything else.
--
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
