I got this problem since 3.8.5 + for-linus (from that time).
Have just tried 3.8.6 + for-linus with git merge -X theirs
btrfs/for-linus but still same problem.
Going back to 3.7.4 + for-linus (from that time) doesn't give me the problem.
This is an production nfs server with 2x2TB raid1, so cant
when we have to report no such file error for
/dev/btrfs-control we could confirm if btrfs kernel
is present and report it and skip registration
where appropriate
v1-v2: use /proc/filesystems to check if the btrfs
is present
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-device.c | 56
On Wed, April 10, 2013 at 09:58 (+0200), Ahmet Inan wrote:
I got this problem since 3.8.5 + for-linus (from that time).
Have just tried 3.8.6 + for-linus with git merge -X theirs
btrfs/for-linus but still same problem.
Going back to 3.7.4 + for-linus (from that time) doesn't give me the
The real problem, however, is not caused by that commit but by a tree mod log
bug. I expect that fs/btrfs/ctree.c:1144 is this BUG_ON in your kernel from
__tree_mod_log_rewind (my line numbers don't match):
1138 switch (tm-op) {
1139 case
When an entry was added to the subvol search tree, the root_id was
always 0 (not set at all) and therefore only the first one was
added, all the others had been ignored. This commit sets the root_id
before the entry is added.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
v1 - v2:
-
From: Wang Shilong wangsl-f...@cn.fujitsu.com
The first patch removes some BUG_ONs() when walking backref tree.
These BUG_ON()s can only be triggered because of ENOMEM, and the caller
has checked the return value about it. So we just return directly rather
than trigger BUG_ON() when out of memory
From: Wang Shilong wangsl-f...@cn.fujitsu.com
The only error return value of __add_prelim_ref() is -ENOMEM,
just return errors rather than trigger BUG_ON().
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
---
fs/btrfs/backref.c | 10 +++---
1 files changed, 7 insertions(+), 3
From: Wang Shilong wangsl-f...@cn.fujitsu.com
__merge_refs() and __add_missing_keys() always return 0, it is unnecessary
for the caller to check the return value.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
---
fs/btrfs/backref.c | 18 +-
1 files changed, 5
Hello,
Maybe this url will help you.
https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories
Thanks,
Wang
Hello,
I'm trying to build btrfs-prog on debian squeeze but when I'm trying to use
make, I have an error :
pc@debian:~/b/btrfs-progs$ make
[LD] mkfs.btrfs
Hello,
this is awesome news! thank you for working on dedup.
I have some questions about the dedup approach in regards to other
layers/features.
1/ How will the snapshots be handled?
Whether data would be dedup-ed between snapshots (potentially big saved-space
ratio), or would snapshots
On Wed, Apr 10, 2013 at 02:05:32PM +0200, Marek Otahal wrote:
Hello,
this is awesome news! thank you for working on dedup.
Hi,
Your previous thread floating on the LIST did give me some light, thanks :)
I have some questions about the dedup approach in regards to other
layers/features.
I was running fsstress to trigger a tree mod log problem on a current kernel
with some custom debug patches applied, so if anyone looking at this needs any
line numbers let me know:
4[ 1221.749586] [ INFO: possible circular locking dependency detected ]
4[ 1221.749589] 3.8.0+ #9 Not tainted
4[
On Wed, Apr 10, 2013 at 07:22:50PM +0800, Wang Shilong wrote:
From: Wang Shilong wangsl-f...@cn.fujitsu.com
The only error return value of __add_prelim_ref() is -ENOMEM,
just return errors rather than trigger BUG_ON().
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Reviewed-by:
On Wed, Apr 10, 2013 at 07:22:51PM +0800, Wang Shilong wrote:
From: Wang Shilong wangsl-f...@cn.fujitsu.com
__merge_refs() and __add_missing_keys() always return 0, it is unnecessary
for the caller to check the return value.
ok for __merge_refs, nak for __add_missing_keys: there's unhandled
On Wed, Apr 10, 2013 at 04:34:03PM +0200, Jan Schmidt wrote:
I was running fsstress to trigger a tree mod log problem on a current kernel
with some custom debug patches applied, so if anyone looking at this needs any
line numbers let me know:
4[ 1221.749586] [ INFO: possible circular locking
On Mon, Apr 08, 2013 at 09:56:44PM +0800, Liu Bo wrote:
Yeah, that's right, I missed this, what about another sanity check for
overlapping ranges, of course in the case of the same file?
Yes of course, I can't work right without it.
david
--
To unsubscribe from this list: send the line
On Mon, Apr 08, 2013 at 10:08:54PM +0800, Liu Bo wrote:
Is it safe to use just 64 bits? I'd like to see better reasoning why
this is ok. The limitation of btrfs_key to store only 1-2 64bit items is
clear and must be handled, but it's IMO a critical design point.
Actually I use the whole
On Tue, Apr 09, 2013 at 09:52:42AM +0800, Miao Xie wrote:
Onmon, 8 Apr 2013 15:47:27 +0200, David Sterba wrote:
This also depends on file data type and access patterns, fixing the dedup
basic chunk size to one block does not IMHO fit most usecases.
Maybe we can make btrfs(including
On Fri, Apr 05, 2013 at 09:05:03AM -0400, Josef Bacik wrote:
On Fri, Apr 05, 2013 at 05:38:16AM -0600, Jan Schmidt wrote:
+static long btrfs_ioctl_quota_rescan_status(struct file *file, void __user
*arg)
+{
+ struct btrfs_root *root = BTRFS_I(fdentry(file)-d_inode)-root;
+
On Fri, Apr 05, 2013 at 01:38:16PM +0200, Jan Schmidt wrote:
+ if (root-fs_info-qgroup_flags BTRFS_QGROUP_STATUS_FLAG_RESCAN) {
I was wondering if merging qgroup_flags with fs_state would make sense
to you. There are currently 3 bits for qgroups, and it's a whole
filesystem state anyway.
Two new flags are added to allow omitting the stream header and the
end command for btrfs send streams. This is used in cases where you
send multiple snapshots back-to-back in one stream.
This used to be encoded like this (with 2 snapshots in this example):
stream header + sequence of commands +
This commit adds a command line option to enable sending streams
which make use of the new end-cmd semantic if multiple snapshots are
sent back-to-back. The goal is to use the end cmd as an indication
to stop reading the input stream. So far, the receiver could only
use EOF to recognize the end.
Hi Miao,
I attempted to fix the issue by not joining a transaction that has
trans-in_commit set. I did something similar to what
wait_current_trans() does, but I did:
smp_rmb();
if (cur_trans cur_trans-in_commit) {
...
wait_event(root-fs_info-transaction_wait, !cur_trans-blocked);
...
I also
We had a discussion on this topic in another thread.
I'd be happy to be corrected, but I think the conclusion was that you
probably need to be on a really modern version of Linux to work with
the latest version of btrfs-progs that is in the kernel git
repository.
The mkfs.btrfs version in the
On 4/10/13 7:28 PM, Mitch Harder wrote:
We had a discussion on this topic in another thread.
I'd be happy to be corrected, but I think the conclusion was that you
probably need to be on a really modern version of Linux to work with
the latest version of btrfs-progs that is in the kernel git
On wed, 10 Apr 2013 21:45:43 +0300, Alex Lyakas wrote:
Hi Miao,
I attempted to fix the issue by not joining a transaction that has
trans-in_commit set. I did something similar to what
wait_current_trans() does, but I did:
smp_rmb();
if (cur_trans cur_trans-in_commit) {
...
Walking backref tree and btrfs quota rely on ulist very much.
This patch tries to use rb_tree to speed up search time.
The original code always checks whether an element
exists before adding a new element, however it costs O(n).
I try to add a rb_tree in the ulist,this is only used to speed up
27 matches
Mail list logo
