linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Swâmi Petaramesh" <swami@petaramesh.org>
To: linux-btrfs@vger.kernel.org
Subject: Re: Using noCow with snapshots ?
Date: Thu, 10 Apr 2014 10:22:15 +0200	[thread overview]
Message-ID: <3839313.LSaoXm11Qk@zafu> (raw)
In-Reply-To: <pan$77cb2$eaaf65a0$d47fcc2f$d279fdb@cox.net>

Thanks Duncan for the perfect explanations.

>From this, I understand that I might get both better performance by setting my 
akonadi dir to "nocow", and still be able to take a snapshot from time to 
time, which is exactly what I need.

Besides this, I'm still wondering about the changes in data security that 
turning a database to "NoCow" would bring, i.e. would the data still be well 
protected in case of a system crash or power failure ?

I have precious data in there and wouldn't like to jeopardize its security for 
a performance gain...

Kind regards.


Le mercredi 9 avril 2014 11:56:20 Duncan a écrit :
> Good questions. =:^)
> 
> #2. That's from one of the devs when the question came up perhaps a 
> couple months ago.
> 
> On a NOCOW file the first write to a fileblock (4096 bytes) after a 
> snapshot must still be COW, because the snapshot locks the old version in 
> place, and now the fileblock has changed, so it MUST be written elsewhere 
> despite the NOCOW in ordered to keep the snapshot as it was.  However, 
> the file does retain the NOCOW attribute and additional writes to the 
> same fileblock will be in-place... until the next snapshot of course.
> 
> This is why on filesystems with scripted snapshots as close as a minute a 
> part (I even saw one guy say he was doing them every 30 seconds!!), 
> setting NOCOW has very little value -- they aren't NOCOW on the first 
> write after a snapshot, and with snapshots happening every minute...,  
> Hourly snapshots are still likely to be a problem on a regularly changing 
> file, tho with daily snapshots you'd probably save some fragmentation 
> over the fairly short term anyway, but it'd still be a problem longer 
> term.
> 
> Which is why I suggest putting such files on a separate subvolume and not 
> snapshotting that subvolume, since snapshots stop at the subvolume 
> boundary.  That gives NOCOW a chance to actually *BE* NOCOW.

-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E


  reply	other threads:[~2014-04-10  8:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-09 11:15 Using noCow with snapshots ? Swâmi Petaramesh
2014-04-09 11:41 ` Hugo Mills
2014-04-09 11:56 ` Duncan
2014-04-10  8:22   ` Swâmi Petaramesh [this message]
2014-04-10 13:19     ` George Eleftheriou
2014-04-10 14:58     ` Duncan
2014-05-07  5:36       ` Russell Coker
2014-05-07 11:09         ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3839313.LSaoXm11Qk@zafu \
    --to=swami@petaramesh.org \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).