Re: zero-length files in snapshots

[Ravi Pinjala <ravi@p-static.net>]

On 02/12/10 09:19, Josef Bacik 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<cjb@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,
>
> Josef
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Is there a race in there? It seems like if a process starts modifying a 
file between the sync and the snapshot, data could still be lost. Is 
there something else going on here that I'm missing that would prevent 
this race?

--Ravi