On Thu, Jun 23, 2011 at 8:54 AM, Peter Schuller <peter.schul...@infidyne.com > 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: http://en.wikipedia.org/wiki/XFS ... Snapshots 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 LVM<http://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29> 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 suspended[4]<http://en.wikipedia.org/wiki/XFS#cite_note-3> and volume manager was unable to create a consistent 'hot' snapshot to backup a heavily busy database.[5]<http://en.wikipedia.org/wiki/XFS#cite_note-4> Fortunately this is no longer the case. Since Linux 2.6.29 ext3, ext4, gfs2 and jfs have the freeze feature as well.[6]<http://en.wikipedia.org/wiki/XFS#cite_note-5> ... 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.
