Am Fri, 17 Nov 2017 06:51:52 +0300 schrieb Andrei Borzenkov <arvidj...@gmail.com>:
> 16.11.2017 19:13, Kai Krakow пишет: > ... > > > BTW: From user API perspective, btrfs snapshots do not guarantee > > perfect granular consistent backups. > > Is it documented somewhere? I was relying on crash-consistent > write-order-preserving snapshots in NetApp for as long as I remember. > And I was sure btrfs offers is as it is something obvious for > redirect-on-write idea. I think it has ordering guarantees, but it is not as atomic in time as one might think. That's the point. But devs may tell better. > > A user-level file transaction may > > still end up only partially in the snapshot. If you are running > > transaction sensitive applications, those usually do provide some > > means of preparing a freeze and a thaw of transactions. > > > > Is snapshot creation synchronous to know when thaw? I think you could do "btrfs snap create", then "btrfs fs sync", and everything should be fine. > > I think the user transactions API which could've been used for this > > will even be removed during the next kernel cycles. I remember > > reiserfs4 tried to deploy something similar. But there's no > > consistent layer in the VFS for subscribing applications to > > filesystem snapshots so they could prepare and notify the kernel > > when they are ready. > > I do not see what VFS has to do with it. NetApp works by simply > preserving previous consistency point instead of throwing it away. > I.e. snapshot is always last committed image on stable storage. Would > something like this be possible on btrfs level by duplicating current > on-disk root (sorry if I use wrong term)? I think btrfs gives the same consistency. But the moment you issue "btrfs snap create" may delay snapshot creation a little bit. So if your application relies on exact point in time snapshots, you need to ensure synchronizing your application to the filesystem. I think the same is true for NetApp. I just wanted to point that out because it may not be obvious, given that btrfs snapshot creation is built right into the tool chain of filesystem itself, unlike e.g. NetApp or LVM, or other storage layers. Background: A good while back I was told that btrfs snapshots during ongoing IO may result in some of the later IO carried over to before the snapshot. Transactional ordering of IO operations is still guaranteed but it may overlap with snapshot creation. So you can still loose a transaction you didn't expect to loose at that point in time. So I understood this as: If you just want to ensure transactional integrity of your database, you are all fine with btrfs snapshots. But if you want to ensure that a just finished transaction makes it into the snapshot completely, you have to sync the processes. However, things may have changed since then. -- Regards, Kai Replies to list-only preferred. -- 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
