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
> re
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
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 ne
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 05:
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 wrote:
> I deleted a subvolume using "rm -rf .snapshots" (t
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 children
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
---
V1->V2: use && instead of ||
fs/btrfs/qgroup.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/fs/
On 01/23/2014 06:42 PM, Filipe David Manana wrote:
On Thu, Jan 23, 2014 at 9:45 PM, Josef Bacik 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
---
fs/btrfs/qgroup.c | 18 +++
On Thu, Jan 23, 2014 at 9:45 PM, Josef Bacik 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
> ---
> fs/btrfs/qgroup.c | 18 +-
> 1 file changed, 13 insertions(
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 sn
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 ali
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 BTR
-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 i
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
---
fs/btrfs/qgroup.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgro
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
s
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 children
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 tha
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 thrott
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
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 b
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 infras
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 'backwar
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 contention.
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 th
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 tri
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
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 the
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
28 matches
Mail list logo
