Convert man page for btrfs-restore, which I forgot to convert in the
previous patchset. :P
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Documentation/Makefile | 1 +
Documentation/btrfs-restore.txt | 72 +
2 files changed, 73
Add btrfs wiki page reference to btrfs-check/btrfsck, btrfs-restore and
btrfs-device as supplement.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Documentation/btrfs-check.txt | 5 +
Documentation/btrfs-device.txt | 10 --
Documentation/btrfs-restore.txt | 4
When executing 'btrfs pro get' on a file which is not compressed, return
value will always be 50 since prop_compress() return -ENOATTR.
But this should be ignored and other prop_XXX() returns 0, so when
prop_compress() is executed on uncompress file, it should return 0.
Signed-off-by: Qu Wenruo
Convert the man page for the newly added btrfs-property subcommand.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Documentation/Makefile | 1 +
Documentation/btrfs-property.txt | 69
2 files changed, 70 insertions(+)
create mode 100644
On Tue, Apr 15, 2014 at 8:04 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
When executing 'btrfs pro get' on a file which is not compressed, return
value will always be 50 since prop_compress() return -ENOATTR.
But this should be ignored and other prop_XXX() returns 0, so when
prop_compress()
Original Message
Subject: Re: [PATCH 4/4] btrfs-progs: Fix the return value when
executing 'btrfs pro get' on a uncompress file.
From: Filipe David Manana fdman...@gmail.com
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年04月15日 17:09
On Tue, Apr 15, 2014 at 8:04 AM, Qu
When executing 'btrfs pro get' on a file which is not compressed, return
value will always be 50 since prop_compress() return -ENOATTR.
But the codes have already check the errno to avoid unnecessary error
message, so the return value should also set to 0.
Signed-off-by: Qu Wenruo
On Tue, Apr 15, 2014 at 10:22 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
When executing 'btrfs pro get' on a file which is not compressed, return
value will always be 50 since prop_compress() return -ENOATTR.
But the codes have already check the errno to avoid unnecessary error
message, so
Hi,
I'm new to btrfs, just dipping my toes in the water...
I've got two partitions, / on /dev/sda2 and /home on /dev/sda3, both
formatted as btrfs in a new openSUSE 13.1 installation. I copied the
whole of /home (4 users) into the btrfs formatted /home partition from
an ext4 backup.
I would
On Tue, Apr 15, 2014 at 02:10:54PM +0100, Bob Williams wrote:
Hi,
I'm new to btrfs, just dipping my toes in the water...
I've got two partitions, / on /dev/sda2 and /home on /dev/sda3, both
formatted as btrfs in a new openSUSE 13.1 installation. I copied the
whole of /home (4 users) into
On 15/04/14 15:16, Hugo Mills wrote:
On Tue, Apr 15, 2014 at 02:10:54PM +0100, Bob Williams wrote:
Hi,
I'm new to btrfs, just dipping my toes in the water...
I've got two partitions, / on /dev/sda2 and /home on /dev/sda3, both
formatted as btrfs in a new openSUSE 13.1 installation. I copied
I lost track of these patches at 3.14 development cycle, they accompany the
subvolume RO protections during send. Would be good to get them to 3.15 but I
understand this may be too late.
David Sterba (2):
btrfs: protect snapshots from deleting during send
btrfs: assert that send is not in
CC: Miao Xie mi...@cn.fujitsu.com
CC: Wang Shilong wangsl.f...@cn.fujitsu.com
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ioctl.c |1 +
fs/btrfs/transaction.c | 13 -
2 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/fs/btrfs/ioctl.c
The patch Btrfs: fix protection between send and root deletion
(18f687d538449373c37c) does not actually prevent to delete the snapshot
and just takes care during background cleaning, but this seems rather
user unfriendly, this patch implements the idea presented in
On Apr 15, 2014, at 7:10 AM, Bob Williams li...@barrowhillfarm.org.uk wrote:
Hi,
I'm new to btrfs, just dipping my toes in the water...
I've got two partitions, / on /dev/sda2 and /home on /dev/sda3, both
formatted as btrfs in a new openSUSE 13.1 installation. I copied the
whole of
On 04/15/2014 10:41 AM, David Sterba wrote:
The patch Btrfs: fix protection between send and root deletion
(18f687d538449373c37c) does not actually prevent to delete the snapshot
and just takes care during background cleaning, but this seems rather
user unfriendly, this patch implements the idea
This increases the send stream version from version 1 to version 2, adding
2 new commands:
1) total data size - used to tell the receiver how much file data the stream
will add or update;
2) fallocate - used to pre-allocate space for files and to punch holes in files.
This is preparation
The send stream version 2 adds the fallocate command, which can be used to
allocate extents for a file or punch holes in a file. Previously we were
ignoring file prealloc extents or treating them as extents filled with 0
bytes and sending a regular write command to the stream.
After this change,
This new send flag makes send calculate first the amount of new file data (in
bytes)
the send root has relatively to the parent root, or for the case of a
non-incremental
send, the total amount of file data the stream will create (including holes and
prealloc
extents). In other words, it
Instead of sending a write command with a data buffer filled with 0 value bytes,
use the fallocate command, introduced in the send stream version 2, to tell the
receiver to punch a file hole using the fallocate system call.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
This is a followup to the kernel patch titled:
Btrfs: send, implement total data size command to allow for progress
estimation
This makes the btrfs send and receive commands aware of the new send flag,
named BTRFS_SEND_C_TOTAL_DATA_SIZE, which tells us the amount of file data
that is new
This increases the send stream version from version 1 to version 2, adding
2 new commands:
1) total data size - used to tell the receiver how much file data the stream
will add or update;
2) fallocate - used to pre-allocate space for files and to punch holes in files.
This is preparation
On Tue, Apr 15, 2014 at 10:52:14AM -0400, Chris Mason wrote:
On 04/15/2014 10:41 AM, David Sterba wrote:
The patch Btrfs: fix protection between send and root deletion
(18f687d538449373c37c) does not actually prevent to delete the snapshot
and just takes care during background cleaning, but
On 04/15/2014 11:44 AM, David Sterba wrote:
On Tue, Apr 15, 2014 at 10:52:14AM -0400, Chris Mason wrote:
On 04/15/2014 10:41 AM, David Sterba wrote:
The patch Btrfs: fix protection between send and root deletion
(18f687d538449373c37c) does not actually prevent to delete the snapshot
and just
When specifying -vv print information about received write and clone commands
too,
as we do this for other commands already and it's very useful for debugging and
troubleshooting.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
cmds-receive.c | 9 +
1 file changed, 9
This test verifies that after an incremental btrfs send the replicated file has
the same exact hole and data structure as in the origin filesystem. This didn't
use to be the case before the send stream version 2 - holes were sent as write
operations of 0 valued bytes instead of punching holes with
The fallocate send stream command, added in stream version 2, is used to
pre-allocate space for files and punch file holes. This change implements
the callback for that new command, using the fallocate function from the
standard C library to carry out the specified action (allocate file space
or
On Fri, Apr 11, 2014 at 11:23:31AM +, Alex wrote:
People: for auto snapshots use Snapper (a la SUSE) which is now in Debian et
al. Only peculiarity is that clear-down of daily snapshots only happens in
the night so you don't need to put many/any hourly snapshots in.
Can be fixed by copying
On Tue, Apr 15, 2014 at 12:00:49PM -0400, Chris Mason wrote:
I'm worried about the use case where we have:
* periodic automated snapshots
* periodic automated deletion of old snapshots
* periodic send for backup
The automated deletion doesn't want to error out if send is in
There's a case which clone does not handle and used to BUG_ON instead,
(testcase xfstests/btrfs/035), now returns EINVAL. This error code is
confusing to the ioctl caller, as it normally signifies errorneous
arguments.
Change it to ENOPNOTSUPP which allows a fall back to copy instead of
clone.
On Tue, Apr 15, 2014 at 03:04:51PM +0800, Qu Wenruo wrote:
Add btrfs wiki page reference to btrfs-check/btrfsck, btrfs-restore and
btrfs-device as supplement.
I'd rather avoid any references to 'btrfsck', it's been deprecated and
'btrfs check' should be used, thouth I'm sure there are enough
NoDuncan 1i5t5.duncan at XXX writes:
Wow Duncan! Thank you so much for your extensive post. Well written and very
well received.
I do think your 'critical bit' comments are worth iterating! I've booked
marked your email!
Qu: By-the-by does know how to re-lay the CRCs down again?
I don't seem
On 04/15/2014 12:27 PM, David Sterba wrote:
On Tue, Apr 15, 2014 at 12:00:49PM -0400, Chris Mason wrote:
I'm worried about the use case where we have:
* periodic automated snapshots
* periodic automated deletion of old snapshots
* periodic send for backup
The automated deletion
On Tue, Apr 15, 2014 at 05:40:18PM +0100, Filipe David Borba Manana wrote:
This increases the send stream version from version 1 to version 2, adding
2 new commands:
1) total data size - used to tell the receiver how much file data the stream
will add or update;
2) fallocate - used to
On Tue, Apr 15, 2014 at 6:41 PM, Mark Fasheh mfas...@suse.de wrote:
On Tue, Apr 15, 2014 at 06:34:38PM +0100, Filipe David Manana wrote:
On Tue, Apr 15, 2014 at 6:28 PM, Mark Fasheh mfas...@suse.de wrote:
On Tue, Apr 15, 2014 at 05:40:18PM +0100, Filipe David Borba Manana wrote:
This
This test case verifies the btrfs properties feature, a new feature
introduced in the linux kernel version 3.14.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
common/rc | 9 +++
tests/btrfs/048 | 220
On Tue, Apr 15, 2014 at 11:50 AM, David Sterba dste...@suse.cz wrote:
There's a case which clone does not handle and used to BUG_ON instead,
(testcase xfstests/btrfs/035), now returns EINVAL. This error code is
confusing to the ioctl caller, as it normally signifies errorneous
arguments.
On Tue, Apr 15, 2014 at 07:30:51PM +0100, Filipe David Manana wrote:
On Tue, Apr 15, 2014 at 7:10 PM, Josef Bacik jba...@fb.com wrote:
Just make a SUPPORTS_V2 flag that userspace can pass in through the
existing flags to make the kernel spit out V2 commands. We don't want to
break old
On Tue, Apr 15, 2014 at 8:35 PM, Mark Fasheh mfas...@suse.de wrote:
On Tue, Apr 15, 2014 at 07:30:51PM +0100, Filipe David Manana wrote:
On Tue, Apr 15, 2014 at 7:10 PM, Josef Bacik jba...@fb.com wrote:
Just make a SUPPORTS_V2 flag that userspace can pass in through the
existing flags to
On Tue, Apr 15, 2014 at 05:43:21PM +0100, Filipe David Borba Manana wrote:
This test verifies that after an incremental btrfs send the replicated file
has
the same exact hole and data structure as in the origin filesystem. This
didn't
use to be the case before the send stream version 2 -
On Tue, Apr 15, 2014 at 08:50:24PM +0100, Filipe David Borba Manana wrote:
This test case verifies the btrfs properties feature, a new feature
introduced in the linux kernel version 3.14.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
...
---
common/rc | 9 +++
Original Message
Subject: Re: [PATCH] btrfs-progs: Force 'btrfs dev scan' not using old
libblkid cache
From: David Sterba dste...@suse.cz
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年04月15日 00:29
On Thu, Apr 10, 2014 at 03:30:21PM +0800, Qu Wenruo wrote:
'btrfs scan'
Original Message
Subject: Re: [PATCH] btrfs-progs: Force 'btrfs dev scan' not using old
libblkid cache
From: Qu Wenruo quwen...@cn.fujitsu.com
To: dste...@suse.cz, linux-btrfs@vger.kernel.org
Date: 2014年04月16日 09:24
Original Message
Subject: Re: [PATCH]
43 matches
Mail list logo
