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@xxxxxxxxxxxxxx> http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
