From: Hubert Kario <hka@qbs.com.pl>
To: Liu Bo <liubo2009@cn.fujitsu.com>
Cc: kreijack@inwind.it, "Matthias G. Eckermann" <mge@suse.com>,
Alex <alex@bpmit.com>,
linux-btrfs@vger.kernel.org
Subject: Re: Create subvolume from a directory?
Date: Tue, 01 May 2012 19:09:21 +0200 [thread overview]
Message-ID: <8026880.aVIK1HJLHr@bursa01> (raw)
In-Reply-To: <4F73B9DC.3040402@cn.fujitsu.com>
On Thursday 29 of March 2012 09:24:44 Liu Bo wrote:
> On 03/29/2012 12:54 AM, Goffredo Baroncelli wrote:
> > Could you elaborate which would be the issue ?
> > "cp --reflink"-ing a file is not different than snapshotting a file=
=2E In
> > any case I could mount a snapshot and not the source subvolume.
>=20
> We already have a debate about this "cross-link device":
> http://comments.gmane.org/gmane.comp.file-systems.btrfs/9864
>=20
> "cp --reflink" will use clone feature, which can share data among fil=
es, but
> metadata is preserved individually.
>=20
> My case is that I can mount both a subvolume and a snapshot via "-o
> subvol=3Dxxx" or "-o subvolid=3Dxxx".
And how is this different from regular snapshot of subvolume? In the en=
d you=20
get two files pointing to same data on the disk while having different=20
metadata.
Let me rephrase it:
People don't want to be able to do:
mount /dev/lvm/btrfs /mnt/a -t btrfs -o subvol=3DvolA
mount /dev/lvm/btrfs /mnt/b -t btrfs -o subvol=3DvolB
cp --reflink=3Dalways /mnt/a/file /mnt/b
Just like you can't do hardlinks over `mount --bind` mountpoints, you=20
shouldn't be able to cp reflink over mountpoints. That's expected as th=
is=20
*does* break VFS semantics.
*But* people want to be able to do this:=20
mount /dev/lvm/btrfs /mnt/ -t btrfs
btrfs subvol create /mnt/subvol
big-file-creator > /mnt/subvol/BIG-file
btrfs subvol snapshot /mnt/subvol /mnt/subvol-bak
big-file-editor /mnt/subvol/BIG-file
rm /mnt/subvol-bak/BIG-file
cp --reflink=3Dalways /mnt/subvol/BIG-file /mnt/subvol-bak/BIG-file
This does not cross any VFS boundaries.
Regards,
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
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
next prev parent reply other threads:[~2012-05-01 17:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-27 17:19 Create subvolume from a directory? Alex
2012-03-27 20:42 ` Chester
2012-03-27 22:24 ` Matthias G. Eckermann
2012-03-28 1:46 ` Fajar A. Nugraha
2012-03-28 9:20 ` David Sterba
2012-03-28 2:18 ` Liu Bo
2012-03-28 16:54 ` Goffredo Baroncelli
2012-03-29 1:24 ` Liu Bo
2012-05-01 17:09 ` Hubert Kario [this message]
2012-05-02 16:33 ` David Sterba
2012-05-03 13:26 ` Hubert Kario
2012-05-14 12:36 ` David Sterba
2012-03-28 9:24 ` David Sterba
2012-03-28 11:11 ` Alex
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=8026880.aVIK1HJLHr@bursa01 \
--to=hka@qbs.com.pl \
--cc=alex@bpmit.com \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=liubo2009@cn.fujitsu.com \
--cc=mge@suse.com \
/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