On Fri, Feb 12, 2010 at 7:19 AM, Josef Bacik <jo...@redhat.com> wrote: > On Thu, Feb 11, 2010 at 08:50:48PM -0800, Mike Fedyk wrote: >> On Thu, Feb 11, 2010 at 7:11 PM, Chris Ball <c...@laptop.org> wrote: >> > > echo x1 > /mnt/x/d/foo.txt || exit 2 >> > > btrfsctl -s /mnt/x/snap /mnt/x/d >> > >> > You're just missing a sync/fsync() between these two lines. >> > >> > We argued on IRC a while ago about whether this is a sensible default; >> > cmason wants the no-sync version of snapshot creation to be available, >> > but was amenable to the idea of changing the default to be sync before >> > snapshot, since it was pointed out that no-one other than him had >> > understood we were supposed to be running sync first. >> > >> You're saying that it only snapshots the on-disk data structures and >> not the in-memory versions? That can only lead to pain. What do you >> do if something else during this race condition? What would a sync do >> to solve this? Have the semantics of sync been changed in btrfs from >> "sync everything that hasn't been written yet" to "sync this >> subvolume"? >> > > Welcome to delalloc. You either get fast writes or you get all of your data > on > the disk every 5 seconds. If you don't like delalloc, use ext3. The data > you've written to memory doesn't go down to disk unless explicitly told to, > such > as > > 1) fsync - this is obvious > 2) vm - the vm has decided that this dirty page has been sitting around long > enough and should be written back to the disk, could happen now, could happen > 10 > years from now. > 3) sync - this is not as obvious. sync doesn't mean anything than "start > writing back dirty data to the fs", and returns before it's done. For btrfs > what that means is we run through _every_ inode that has delalloc pages > associated with them and start writeback on them. This will get most of your > data into the current transaction, which is when the snapshot happens. > > If you don't want empty files, do something like this > > btrfsctl -c /dir/to/volume > btrfsctl -s /dir/to/volume/snapshotname /dir/to/volume > > this is what we do with yum and its rollback plugin, and it works out quite > well. Thanks, >
Then you broke your ordering guarantee. If the data isn't there, the meta-data shouldn't be there either. So the snapshots made before the data hits a transaction shouldn't have the file at all. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
