On Thu, 23 Jan 2014 15:42:37 +0800, Wang Shilong wrote:
Hi David,
On 01/21/2014 11:56 PM, David Sterba wrote:
Commit Btrfs-progs: make send/receive compatible with older kernels
adds code that will become deprecated, let's clearly mark it in the
sources.
CC: Stefan Behrens
Hi
Sending snapshots incrementally started to fail on the 3.11 kernel on my
system after I once booted with 3.12 and did the incremental send of a
snapshot. After when I booted back to 3.11 I can no longer send the
snapshots incrementally based on the last one sent (I could still send
based on
Am 23.01.2014 10:22, schrieb Miguel Negrão:
Hi
Sending snapshots incrementally started to fail on the 3.11 kernel
on my system after I once booted with 3.12 and did the incremental
send of a snapshot. After when I booted back to 3.11 I can no
longer send the snapshots incrementally based
On Thu, Jan 23, 2014 at 05:47:02AM +, Ben Hutchings wrote:
I'm sending this on to the btrfs developers to see if they can help.
On Tue, 2014-01-21 at 11:00 +0200, Giorgos Pallas wrote:
[...]
I just installed 3.12-amd64 stock kernel. It booted OK, I opened a konsole
and just tried to
On 01/23/2014 04:22 AM, Miguel Negrão wrote:
Hi
Sending snapshots incrementally started to fail on the 3.11 kernel on my
system after I once booted with 3.12 and did the incremental send of a
snapshot. After when I booted back to 3.11 I can no longer send the
snapshots incrementally based on
Currently we have two rb-trees, one for delayed ref heads and one for all of the
delayed refs, including the delayed ref heads. When we process the delayed refs
we have to hold onto the delayed ref lock for all of the selecting and merging
and such, which results in quite a bit of lock
On Thu, Jan 23, 2014 at 01:28:54PM +0100, Joshua Schüler wrote:
btrfs guarantees backward compatibility since 3.13(?), but never
guaranteed forward compatibility.
Isnt' this the opposite way? Forward means that old fs will be mountable
on a newer kernel.
I don't know what you mean by 'backward
On Mon, Jan 20, 2014 at 01:17:08AM +0100, George Eleftheriou wrote:
Without having further knowledge on that matter, I tend to believe
(but I hope I'm wrong) that BTRFS is as vulnerable as ZFS to memory
errors. Since I upgraded recently, it's a bit too late for purchasing
ECC-capable
On Tue, Jan 07, 2014 at 11:51:08AM +, Filipe David Manana wrote:
There seems to be a lot of details for this feature, and many other
projects (such as those you point on the wiki) would benefit from
properties.
It might be hard to get all requirements at once, so I think it might
be
Em 23-01-2014 14:19, Josef Bacik escreveu:
On 01/23/2014 04:22 AM, Miguel Negrão wrote:
Hi
Sending snapshots incrementally started to fail on the 3.11 kernel on my
system after I once booted with 3.12 and did the incremental send of a
snapshot. After when I booted back to 3.11 I can no
On one of our gluster clusters we noticed some pretty big lag spikes. This
turned out to be because our transaction commit was taking like 3 minutes to
complete. This is because we have like 30 gigs of metadata, so our global
reserve would end up being the max which is like 512 mb. So our
On Wed, Jan 22, 2014 at 12:55:39PM -0800, Roger Binns wrote:
There was the theoretical side - ie coming up with a way of defining
perfection which then allows measuring against. For example you have
going up to a 128K block size but without knowing the theoretical best we
don't know if that
On 01/22/2014 05:05 AM, Filipe David Borba Manana wrote:
Regression test for btrfs' incremental send feature:
1) Create several nested directories;
2) Create a read only snapshot;
3) Change the parentship of some of the deepest directories in a reverse
way, so that parents become
I don't think this is an issue and I've not seen it in practice but
extent_from_logical will fail to find a skinny extent because it uses
btrfs_previous_item and gives it the normal extent item type. This is just not
a place to use btrfs_previous_item since we care about either normal extents or
Could have sworn I fixed this before but apparently not. This makes us pass
btrfs/022 with skinny metadata enabled. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
fs/btrfs/qgroup.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/qgroup.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/01/14 10:36, David Sterba wrote:
'Theoretical best' seems too vaguely defined,
It seems like a good thing for someone to tackle as part of a master's
thesis :-)
with compression it's always some trade-off and compromise
Which you can put in
I was wondering about whether using options like autodefrag and
inode_cache on SSDs.
On one hand, one always hears that defragmentation of SSD is a no-no,
does that apply to BTRFS's autodefrag?
Also, just recently, I heard something similar about inode_cache.
On the other hand, Arch BTRFS
I deleted a subvolume using rm -rf .snapshots (the subvolume was
created by snapper). Now, it's gone from the filesystem, but it's
still show in btrfs su list / where it was originally. This makes me
worried. I ran a btrfsck and it didn't spot any errors that seemed
relevant.
The system is alive
Regression test for btrfs' incremental send feature:
1) Create several nested directories;
2) Create a read only snapshot;
3) Change the parentship of some of the deepest directories in a reverse
way, so that parents become children and children become parents;
4) Create another read only
On Thu, Jan 23, 2014 at 9:45 PM, Josef Bacik jba...@fb.com wrote:
Could have sworn I fixed this before but apparently not. This makes us pass
btrfs/022 with skinny metadata enabled. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
fs/btrfs/qgroup.c | 18 +-
1 file
On 01/23/2014 06:42 PM, Filipe David Manana wrote:
On Thu, Jan 23, 2014 at 9:45 PM, Josef Bacik jba...@fb.com wrote:
Could have sworn I fixed this before but apparently not. This makes us pass
btrfs/022 with skinny metadata enabled. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
Could have sworn I fixed this before but apparently not. This makes us pass
btrfs/022 with skinny metadata enabled. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
V1-V2: use instead of ||
fs/btrfs/qgroup.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff
On 01/23/2014 06:38 PM, Filipe David Borba Manana wrote:
Regression test for btrfs' incremental send feature:
1) Create several nested directories;
2) Create a read only snapshot;
3) Change the parentship of some of the deepest directories in a reverse
way, so that parents become
Bleck. It turns out that the output of btrfs su list is always
relative to the root (which makes it an absolute path disguised as a
relative path). Removing it was easy after I realized that.
On Thu, Jan 23, 2014 at 3:37 PM, Jonathan H python...@gmail.com wrote:
I deleted a subvolume using rm
Hello Josef,
I have sent a patch before to address this issue:
https://patchwork.kernel.org/patch/3472211/
I introduced another function btrfs_previous_extent_item() to
search previous extent item, I think you must miss my path before
giving this patch ^_^.
Thanks,
Wang
On 01/24/2014
Hi all,
The xfstests repository at git://oss.sgi.com/xfs/cmds/xfstests has
just been updated. Patches often get missed, so please check if your
outstanding patches were in this update. If they have not been in
this update, please resubmit them to x...@oss.sgi.com so they can be
picked up in the
KC posted on Thu, 23 Jan 2014 23:23:35 +0100 as excerpted:
I was wondering about whether using options like autodefrag and
inode_cache on SSDs.
On one hand, one always hears that defragmentation of SSD is a no-no,
does that apply to BTRFS's autodefrag?
Also, just recently, I heard
On Thu, Jan 23, 2014 at 01:07:52PM -0500, Josef Bacik wrote:
On one of our gluster clusters we noticed some pretty big lag spikes. This
turned out to be because our transaction commit was taking like 3 minutes to
complete. This is because we have like 30 gigs of metadata, so our global
28 matches
Mail list logo
