linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Oliver O." <oliver.o456i@gmail.com>
To: Chris Mason <clm@fb.com>, linux-btrfs@vger.kernel.org
Subject: Re: File changing in snapshot
Date: Thu, 17 Apr 2014 23:29:15 +0200	[thread overview]
Message-ID: <535047AB.6030606@gmail.com> (raw)
In-Reply-To: <534FFD22.1060500@gmail.com>


Am 17.04.2014 18:11, schrieb Oliver O.:
>
> Am 17.04.2014 17:56, schrieb Chris Mason:
>> On 04/17/2014 11:39 AM, Oliver O. wrote:
>>> I seem to have observed a file on a (writable) snapshot changing
>>> although there were no writes occuring on the snapshot itself. This is
>>> not supposed to happen, right?
>>
>> Was this a nodatacow file?
>>
>> -chris
>
> No. Mount options:
>
> /dev/sda2 on /home type btrfs (rw,noatime,nodiratime,subvol=@home)
>

Some additional observations:
- Subvolume used for writing: @home
- Snapshot used for backup: @home-2014-04-16
- Preceding snapshot: @home-2014-04-10

# lsattr -v @home-2014-04-10/path/to/MyFile.xls 
@home-2014-04-16/path/to/MyFile.xls @home/path/to/MyFile.xls
36066 ---------------- @home-2014-04-10/path/to/MyFile.xls
36066 ---------------- @home-2014-04-16/path/to/MyFile.xls
36066 ---------------- @home/path/to/MyFile.xls

# btrfs subvolume find-new @home-2014-04-10 99999999
transid marker was 180026

# btrfs subvolume find-new @home-2014-04-16 99999999
transid marker was 194551

# btrfs subvolume find-new @home 99999999
transid marker was 197735

# btrfs subvolume find-new @home 36066 | grep "MyFile.xls"
inode 24426 file offset 0 len 20480 disk start 9108635648 offset 0 gen 
193090 flags NONE path/to/MyFile.xls
inode 24426 file offset 20480 len 36864 disk start 25510342656 offset 
20480 gen 36067 flags NONE path/to/MyFile.xls
inode 24426 file offset 57344 len 4096 disk start 9108582400 offset 0 
gen 193090 flags NONE path/to/MyFile.xls


Conclusions:

The sequence of events seems to be:

1. The file was changed with generation 193090.
2. The snapshot for backup (@home-2014-04-16) was taken (generation 194551).
3. As the backup was reading from the snapshot, it was seeing stale data 
(MyFile still at generation 36067).
4. As the backup comparison was reading from the snapshot, is was seeing 
more recent data, causing a discrepancy with the stale data just backed up.

It seems that the snapshot needed some time to become stable for 
reading. From a file system user's point of view, I'd expect a snapshot 
to be atomic and stable at any time. Maybe some kind of caching problem 
here?

Maybe it's time to file a bug report, but first: suggestions and ideas 
appreciated.


  reply	other threads:[~2014-04-17 21:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-17 15:39 File changing in snapshot Oliver O.
2014-04-17 15:56 ` Chris Mason
2014-04-17 16:11   ` Oliver O.
2014-04-17 21:29     ` Oliver O. [this message]
2014-04-18 15:50       ` Solved, false alarm - " Oliver O.
2014-04-18 17:08         ` Chris Mason

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=535047AB.6030606@gmail.com \
    --to=oliver.o456i@gmail.com \
    --cc=clm@fb.com \
    --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).