On 07/29/13 10:05, Tomasz Chmielewski wrote:
On Mon, 10 Jun 2013 09:41:39 +0200
Arne Jansen sensi...@gmx.net wrote:
Now, my questions:
- what do both 104882176 104882176 numbers represent?
The first number represents the amount of data in that subvolume,
regardless whether that data is
On 07/31/13 07:39, Tomasz Chmielewski wrote:
On Wed, 31 Jul 2013 13:13:37 +0800
Wang Shilong wangsl.f...@cn.fujitsu.com wrote:
# git pull origin master
Oops, i am sorry, here should:
git pull origin qgroup
would you please try it again
Excellent, it works:
# btrfs qgroup show -p
The rule originally comes from nocow writing, but snapshot-aware
defrag is a different case, the extent has been writen and we're
not going to change the extent but add a reference on the data.
So we're able to allow such compressed extents to be merged into
one bigger extent if they're pointing
On fri, 2 Aug 2013 14:49:54 +0800, Liu Bo wrote:
The rule originally comes from nocow writing, but snapshot-aware
defrag is a different case, the extent has been writen and we're
not going to change the extent but add a reference on the data.
So we're able to allow such compressed extents to
On Fri, Aug 02, 2013 at 04:11:16PM +0800, Miao Xie wrote:
On fri, 2 Aug 2013 14:49:54 +0800, Liu Bo wrote:
The rule originally comes from nocow writing, but snapshot-aware
defrag is a different case, the extent has been writen and we're
not going to change the extent but add a reference on
The rule originally comes from nocow writing, but snapshot-aware
defrag is a different case, the extent has been writen and we're
not going to change the extent but add a reference on the data.
So we're able to allow such compressed extents to be merged into
one bigger extent if they're pointing
A disk just died on this RAID-1 btrfs filesystem running 3.10 - I can
see a kernel BUG at fs/btrfs/extent_io.c:2054!, is it expected to BUG on a
failing drive?
Aug 2 10:21:12 mach-5 kernel: [1589617.888162] Read(16): 88 00 00 00 00 00 35
ee 2f d0 00 00 00 30 00 00
Aug 2 10:21:12 mach-5
Hi, Josef
On Tue, 30 Jul 2013 14:27:40 +0800, Miao Xie wrote:
extent_clear_unlock_delalloc(inode, start, end, NULL,
- EXTENT_DIRTY |
- EXTENT_DELALLOC,
+
On Thu, Jul 18, 2013 at 02:05:31PM -0600, Chris Murphy wrote:
On Jul 18, 2013, at 11:33 AM, David Sterba dste...@suse.cz wrote:
The missing data blocks return IO error and the valid data can be read.
Sounds like if I have a degraded 'single' volume, I can simply cp or
rsync
On Wed, Jul 31, 2013 at 3:23 PM, Josef Bacik jba...@fusionio.com wrote:
Alexandre pointed out that his xattrs have sensitive information in them as
well, so fix btrfs-image to zero out the data part of xattrs that we find.
Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
From: David Sterba
There were a few requests to tune the interval. This finally made me to
finish the patch and will send it in a second.
Thank you, David and to others who kindly replied to my post. I will try your
patch rather than modifying the code
Are there any unforeseen and
v2:
* Stefan pointed out a missing break and that /proc/mounts does not show
the option.
* fixed missing goto and extra printk parameter after failed match_int
Forgive my naive question: I am using gmx's webclient which doesn't seem to
identify your patch as an attachment. I can simply
- Original Message -
From: Mike Audia
Sent: 08/02/13 05:12 PM
To: David Sterba, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] btrfs: add mount option to set commit interval
v2:
* Stefan pointed out a missing break and that /proc/mounts does not show
the option.
* fixed
Another newbie question is which version of the kernel do I need to
have in order to cleanly apply this patch? I am finding that it fails
to apply to the current stable kernel code (as of now it is v3.10.4)
which makes me think your patch has to be applied to a newer one? Are
you patching
On Fri, Aug 02, 2013 at 06:08:01PM +0800, Miao Xie wrote:
Hi, Josef
On Tue, 30 Jul 2013 14:27:40 +0800, Miao Xie wrote:
extent_clear_unlock_delalloc(inode, start, end, NULL,
- EXTENT_DIRTY |
-
Which is 'best' or 'faster'?
Take a snapshot of an existing backup and then rsync --delete into
that to make a backup of some other filesystem?
Or use rsync --link to link a new backup tree against a previous
backup tree for the some other filesystem?
Which case does btrfs handle the better?
On 7/10/13 11:12 AM, David Sterba wrote:
On Tue, Jul 09, 2013 at 07:49:53PM +0100, Filipe David Borba Manana wrote:
The module cmds-restore.c was defining its own next_leaf()
function, which did exactly the same as btrfs_next_leaf()
from ctree.c.
This has been removed by Eric's patch
Port of commit b3b4aa7 to userspace.
parameter tree root it's not used since commit
5f39d397dfbe140a14edecd4e73c34ce23c4f9ee (Btrfs: Create extent_buffer
interface for large blocksizes)
This gets userspace a tad closer to kernelspace by removing
this unused parameter that was all over the
cmds-recieve.c cmds-send.c seem to have weird wrappers and
indirections, and groups of commands which have only
one member, which are never referenced in the code.
I think these can be removed.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
cmds-receive.c | 19 +--
19 matches
Mail list logo
