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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.