Duncan 1i5t5.dun...@cox.net schrieb:
[...]
Difficult to twist your mind around that but well explained. ;-)
A snapshot thus looks much like a crash in terms of NOCOW file integrity
since the blocks of a NOCOW file are simply snapshotted in-place, and
there's already no checksumming or file
Chris Murphy li...@colorremedies.com schrieb:
If the database/virtual machine/whatever is crash safe, then the
atomic state that a snapshot grabs will be useful.
How fast is this state fixed on disk from the time of the snapshot
command? Loosely speaking. I'm curious if this is 1 second; a
On Feb 7, 2014, at 2:07 PM, Kai Krakow hurikhan77+bt...@gmail.com wrote:
Chris Murphy li...@colorremedies.com schrieb:
If the database/virtual machine/whatever is crash safe, then the
atomic state that a snapshot grabs will be useful.
How fast is this state fixed on disk from the time of
Duncan 1i5t5.dun...@cox.net schrieb:
The question here is: Does it really make sense to create such snapshots
of disk images currently online and running a system. They will probably
be broken anyway after rollback - or at least I'd not fully trust the
contents.
VM images should not be
Chris Murphy li...@colorremedies.com schrieb:
On Feb 7, 2014, at 2:07 PM, Kai Krakow hurikhan77+bt...@gmail.com wrote:
Chris Murphy li...@colorremedies.com schrieb:
If the database/virtual machine/whatever is crash safe, then the
atomic state that a snapshot grabs will be useful.
How
Kai Krakow posted on Fri, 07 Feb 2014 23:26:34 +0100 as excerpted:
So the question is: Do btrfs snapshots give the same guarantees on the
filesystem level that write-barriers give on the storage level which
exactly those processes rely upon? The cleanest solution would be if
processes could
Duncan 1i5t5.dun...@cox.net schrieb:
Ah okay, that makes it clear. So, actually, in the snapshot the file is
still nocow - just for the exception that blocks being written to become
unshared and relocated. This may introduce a lot of fragmentation but it
won't become worse when rewriting the
On Thu, Feb 6, 2014 at 6:32 PM, Kai Krakow hurikhan77+bt...@gmail.com wrote:
Duncan 1i5t5.dun...@cox.net schrieb:
Ah okay, that makes it clear. So, actually, in the snapshot the file is
still nocow - just for the exception that blocks being written to become
unshared and relocated. This may
On Feb 6, 2014, at 6:01 PM, cwillu cwi...@cwillu.com wrote:
On Thu, Feb 6, 2014 at 6:32 PM, Kai Krakow hurikhan77+bt...@gmail.com wrote:
Duncan 1i5t5.dun...@cox.net schrieb:
Ah okay, that makes it clear. So, actually, in the snapshot the file is
still nocow - just for the exception that
Kai Krakow posted on Fri, 07 Feb 2014 01:32:27 +0100 as excerpted:
Duncan 1i5t5.dun...@cox.net schrieb:
That also explains the report of a NOCOW VM-image still triggering the
snapshot-aware-defrag-related pathology. It was a _heavily_ auto-
snapshotted btrfs (thousands of snapshots,
David Sterba dste...@suse.cz schrieb:
On Tue, Feb 04, 2014 at 08:22:05PM -0500, Josef Bacik wrote:
On 02/04/2014 03:52 PM, Kai Krakow wrote:
Hi!
I'm curious... The whole snapshot thing on btrfs is based on its COW
design. But you can make individual files and directory contents nocow
by
Kai Krakow posted on Wed, 05 Feb 2014 19:17:10 +0100 as excerpted:
David Sterba dste...@suse.cz schrieb:
On Tue, Feb 04, 2014 at 08:22:05PM -0500, Josef Bacik wrote:
On 02/04/2014 03:52 PM, Kai Krakow wrote:
Hi!
I'm curious... The whole snapshot thing on btrfs is based on its COW
On 02/04/2014 03:52 PM, Kai Krakow wrote:
Hi!
I'm curious... The whole snapshot thing on btrfs is based on its COW design.
But you can make individual files and directory contents nocow by applying
the C attribute on it using chattr. This is usually recommended for database
files and VM images.
On Tue, Feb 04, 2014 at 08:22:05PM -0500, Josef Bacik wrote:
On 02/04/2014 03:52 PM, Kai Krakow wrote:
Hi!
I'm curious... The whole snapshot thing on btrfs is based on its COW design.
But you can make individual files and directory contents nocow by applying
the C attribute on it using
14 matches
Mail list logo
