cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josep Blanquer <>
Subject Re: Backup/Restore: Coordinating Cassandra Nodetool Snapshots with Amazon EBS Snapshots?
Date Thu, 23 Jun 2011 16:11:49 GMT
On Thu, Jun 23, 2011 at 8:54 AM, Peter Schuller <
> wrote:

> > Actually, I'm afraid that's not true (unless I'm missing something). Even
> if
> > you have only 1 drive, you still need to stop writes to the disk for the
> > short time it takes the low level "drivers" to snapshot it (i.e., marking
> > all blocks as clean so you can do CopyOnWrite later). I.e., you need to
> give
> > a chance to LVM, or the EBS low level 'modules' in the hypervisor (
> whatever
> > you use underneath...), to have exclusive control of the drive for a
> moment.
> > Now, that being said, some systems (like LVM)  will do a freeze
> themselves,
> > so technically speaking you don't need to explicitly do a freeze
> > yourself...but that's not to say that a freeze is not required for
> > snapshotting.
> This doesn't make sense unless you can provide some specific reason
> why this would be required. If a file system is crash-consistent,
> relying on write barriers to work, and given that the setup (kernel,
> mounts opts, device driver etc) is such that write barriers are not
> broken, it is directly implied that a consistent snapshot of the under
> lying device is equivalent to a sudden halt (power off, sudden reboot,
> etc).
> If taking an atomic snapshot of the device on which a file system is
> located on, assuming the file system is designed to be crash
> consistent, it *has* to result in a consistent snapshot. Anything else
> would directly violate the claim that the file system is crash
> consistent, making the premise false.
> Peter,

A snippet from the wikipedia page on XFS for example:

XFS does not provide direct support for snapshots, as it expects the
snapshot process to be implemented by the volume manager. Taking a snapshot
of an XFS filesystem involves freezing I/O to the filesystem using the
xfs_freeze utility, having the volume manager perform the actual snapshot,
and then unfreezing I/O to resume normal operations. The snapshot can then
be mounted read-only for backup purposes. XFS releases on IRIX incorporated
an integrated volume manager called XLV. This volume manager has not been
ported to Linux and XFS works with standard
 instead. In recent Linux kernels, thexfs_freeze functionality is
implemented in the VFS layer, and happens automatically when the Volume
Manager's snapshot functionality is invoked. This was once a valuable
advantage as Ext3 system could not be
 and volume manager was unable to create a consistent 'hot' snapshot to
backup a heavily busy database.[5]<>
 Fortunately this is no longer the case. Since Linux 2.6.29 ext3, ext4, gfs2
and jfs have the freeze feature as

I haven't touched the linux kernel for many years now, so I honestly I'm
talking about what I've read in the last few years (rather than relying on
the actual kernel/drivers code). But if I have to trust this and many other
articles like it, I'm interpreting that freezing the FS (directly or
indirectly by LVM) is, indeed, necessary. Not just for XFS but for other
log-based filesystems. Honestly speaking, I'm not sure if the exact
technical reason why...maybe it is to stop reads to the actual device, or to
ensure some sort of log flushing depending on your settings, ... etc.
dunno...erhaps somebody else knows and want to share it.


Josep M.

View raw message