linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shriramana Sharma <samjnaa@gmail.com>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Moving contents from one subvol to another
Date: Sat, 29 Nov 2014 19:51:07 +0530	[thread overview]
Message-ID: <CAH-HCWUR4QPDn=M8nchdRedzGU3DYDHC8d6YRH8-FBm6trWCJg@mail.gmail.com> (raw)

Hello. I am now taking the first steps to making my backup external
HDD in BtrFS. From
http://askubuntu.com/questions/119014/btrfs-subvolumes-vs-folders I
understand that the only difference between subvolumes and ordinary
folders is that the former can be snapshotted and independently
mounted.

But I have a question. I have two subvols test1, test2.

$ cd test1
$ dd if=/dev/urandom of=file bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 36.2291 s, 14.5 MB/s
$ time mv file ../test2/
real    0m2.061s
user    0m0.013s
sys     0m0.459s
$ time { cp --reflink ../test2/file . && rm ../test2/file ; }
real    0m0.677s
user    0m0.022s
sys     0m0.086s
$ mkdir foo
$ time mv file foo/
real    0m0.096s
user    0m0.008s
sys     0m0.013s

It seems that mv is not CoW aware and hence is not able to create
reflinks so it is actually processing the entire file because it
thinks test2 is a different device/filesystem/partition or such. Is
this understanding correct?

So doing cp --reflink with rm is much faster. But it is still slower
than doing mv within the same subvol. Is it because of the
housekeeping with updating the metadata of the two subvols?

Methinks --reflink option should be added to mv for the above usecase.
Do people think this is useful? Why or why not?

My concern is that if somebody wants to consolidate two subvols into
one, though really only the metadata needs to be processed using
ordinary mv isn't aware of this and using cp --reflink with rm is
unnecessarily complicated, especially if it will involve multiple
files.

And it's not clear to me what it would entail to cp --reflink + rm an
entire directory tree because IIUC I'd have to handle each file
separately. Perhaps something (unnecessarily convoluted) like:

find . | while read f
do
[ -d "$f" ] && mkdir target/"$f" && touch target/"$f" -r "$f"
[ -f "$f" ] && cp -a --reflink "$f" target/ && rm "$f"
done

Again, what would happen to files which are not regular directories or files?

And why isn't --reflink given a single letter alias for cp?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

             reply	other threads:[~2014-11-29 14:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-29 14:21 Shriramana Sharma [this message]
2014-11-29 14:28 ` Moving contents from one subvol to another Hugo Mills
2014-11-29 15:15   ` Shriramana Sharma
2014-11-29 17:07     ` Robert White
2014-11-30  3:53       ` Shriramana Sharma
2014-11-30 13:04         ` Shriramana Sharma

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='CAH-HCWUR4QPDn=M8nchdRedzGU3DYDHC8d6YRH8-FBm6trWCJg@mail.gmail.com' \
    --to=samjnaa@gmail.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).