On Thu, Feb 11, 2010 at 7:11 PM, Chris Ball <cjb@xxxxxxxxxx> 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"? >From what I understand what should be happening is much like what LVM should do: step 1: defer all other writes to subvolume (userspace processes get stuck in D state until step 4) step 2: sync all changes not already committed to subvolume step 3: create snapshot step 4: resume writes from userspace Now if all 4 steps can be done with in-memory data structures without forcing data (not necessarily meta-data) to disk, so much the better. -- 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
