public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Pádraig Brady" <P@draigBrady.com>
To: Giuseppe Scrivano <gscrivano@gnu.org>
Cc: bug-coreutils@gnu.org, Jim Meyering <jim@meyering.net>,
	linux-btrfs@vger.kernel.org
Subject: Re: BTRFS file clone support for cp
Date: Tue, 28 Jul 2009 00:40:14 +0100	[thread overview]
Message-ID: <4A6E3ADE.6050008@draigBrady.com> (raw)
In-Reply-To: <87ws5tvrq8.fsf@master.homenet>

Giuseppe Scrivano wrote:
> Jim Meyering <jim@meyering.net> writes:
>=20
>>> Another possible issue with this I can think of is
>>> depending on the modification pattern of the COW files,
>>> the modification processes could fragment the file or
>>> more seriously be given ENOSPC errors.
>> I hope btrfs takes care of this behind the scene.
>>
>> How does the clone work wrt to space consumed, a la df?
>> If copying a 1GB file this way does not update usage
>> stats to reflect the additional 1GB of space used, ...
>=20
> I tried to clone a big file and df reported a different "used blocks"
> stat that it was before the clone operation.

How different exactly?
OK I tried this myself on F11 with inconclusive results.

$ uname -r
2.6.29.6-213.fc11.i586
$ sudo yum install btrfs-progs
# dd bs=3D1M count=3D300 if=3D/dev/zero of=3D/btrfs.img #min size?
# mkfs.btrfs /btrfs.img
# mkdir /btrfs
# mount -o loop /btrfs.img /btrfs
# cd /btrfs
# dd bs=3D1M count=3D100 if=3D/dev/zero of=3Dalloc.test
# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/loop0            300M   28K  300M   1% /btrfs
# df -h . #only allocated about 30s later
Filesystem            Size  Used Avail Use% Mounted on
/dev/loop0            300M  101M  200M  34% /btrfs
# /home/padraig/clone_file alloc.test alloc.test.clone
# umount /btrfs
# mount -o loop /btrfs.img /btrfs
# cd btrfs
# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/loop0            300M  101M  200M  34% /btrfs

OK the above suggests that the clone doesn't take
any space as I would expect. Then it starts getting confusing...

# du -h *
100M    alloc.test
244M    alloc.test.clone #wha?
# dd bs=3D1M count=3D200 if=3D/dev/zero of=3Duse.space
dd: writing `use.space': No space left on device
101+0 records in
100+0 records out
# ls -l
total 454656
-rw-r--r-- 1 root root 104857600 2009-07-28 00:06 alloc.test
-rw-r--r-- 1 root root 104857600 2009-07-28 00:07 alloc.test.clone
-rw-r--r-- 1 root root 104857600 2009-07-28 00:18 use.space
# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/loop0            300M  184M  117M  62% /btrfs

The above suggests that the clone does actually allocate space
but btrfs isn't reporting it through statvfs correctly?
If the clone does allocate space, then how can one
clone without allocation which could be very useful
for snapshotting for example?

Also I tried the above twice and both times got:
http://www.kerneloops.org/submitresult.php?number=3D578993

cheers,
P=E1draig.

       reply	other threads:[~2009-07-27 23:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87d47o3fip.fsf@master.homenet>
     [not found] ` <4A6CEA48.5050208@draigBrady.com>
     [not found]   ` <8763defuvq.fsf@meyering.net>
     [not found]     ` <87ws5tvrq8.fsf@master.homenet>
2009-07-27 23:40       ` Pádraig Brady [this message]
2009-07-28 20:06         ` BTRFS file clone support for cp Giuseppe Scrivano
2009-07-29 13:01           ` Chris Mason
2009-07-29 14:14             ` Pádraig Brady
2009-07-29 16:10               ` Chris Mason
2009-07-29 16:18                 ` Chris Mason
2009-07-29 18:14                 ` Pádraig Brady
2009-07-30  0:57                   ` Joel Becker
2009-07-30  7:39                     ` Jim Meyering
2009-07-30  8:21                       ` Joel Becker
2009-07-30  8:40                       ` Pádraig Brady
2009-07-30 16:28                         ` Ric Wheeler
2009-07-30 16:48                           ` Jim Meyering
2009-07-30  9:26                       ` Andi Kleen
2009-07-30 10:02                         ` Pádraig Brady
2009-07-30 10:16                         ` Jim Meyering
2009-07-30 10:21                           ` Tomasz Chmielewski
2009-07-30 10:54                           ` Andi Kleen
2009-07-30 18:05                             ` Joel Becker
2009-07-30 23:28                               ` Pádraig Brady
     [not found]         ` <87k51r9sxh.fsf@master.homenet>
     [not found]           ` <4A70C4E0.9030104@draigBrady.com>
2009-07-30 17:28             ` Giuseppe Scrivano

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=4A6E3ADE.6050008@draigBrady.com \
    --to=p@draigbrady.com \
    --cc=bug-coreutils@gnu.org \
    --cc=gscrivano@gnu.org \
    --cc=jim@meyering.net \
    --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