On Thu, Jan 10, 2013 at 08:51:59PM +0800, Miao Xie wrote:
> There is no lock to protect fs_info->fs_state, it will introduce some
> problems,
> such as the value may be covered by the other task when several tasks modify
> it. Now we use bit operation for it to fix the above problem.
Can you plea
On Thu, Jan 10, 2013 at 08:53:03PM +0800, Miao Xie wrote:
> We may access and update transaction->abort on the different CPUs without
> lock,
> so we need ACCESS_ONCE() wrapper to make sure we can get the new value.
ACCESS_ONCE is not the right synchronization primitive to be used here,
it is a w
I had a 5 drive array where the SATA port multiplier one drive was in,
crapped out.
After fixing that, and remounting the array, I got a bunch of recovery errors,
including
warnings. They seem like a lot more than I should have, but maybe they're
normal/expected, maybe not (at the bottom of the mi
Hello,
I've already recreated btrfs on the partition, so there'd be nothing
useful to send.
Thanks.
On Thu, Jan 10, 2013 at 10:13 PM, David Sterba wrote:
> On Wed, Jan 09, 2013 at 10:43:24PM -0500, Randy Barlow wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> > kernel is at 3.6.11-1-ARCH
>>
>> Sor
On Thu, Jan 10, 2013 at 08:48:00PM +0800, Miao Xie wrote:
> fs_info->alloc_start was not protected strictly, it might be changed while
> we were accessing it. This patch fixes this problem by using two locks to
> protect it (fs_info->chunk_mutex and sb->s_umount). On the read side, we
> just need g
> > Hmm, I guess it's cool to get the allocation-specific decoding which you
> > don't get from the generic kernel leak tracking?
I mean that by doing this in btrfs, instead of doing it generically in
the allocator, you get specific knowledge that btrfs knows about the
allocated objects:
> > > +
On Tue, Jan 08, 2013 at 10:46:03AM -0800, Marc MERLIN wrote:
> On Tue, Jan 08, 2013 at 01:25:41PM -0500, Josef Bacik wrote:
> > On Tue, Jan 08, 2013 at 09:49:58AM -0700, Marc MERLIN wrote:
> > > Unfortunately my laptop deadlocks from time to time, and too often
> > > it triggers this bug in btrfs w
On Sun, Jan 06, 2013 at 10:30:38PM +0800, Liu Bo wrote:
> 284 misses a 'mkdir' operation.
>
> Signed-off-by: Liu Bo
Tested-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Thu, Jan 10, 2013 at 12:04:58PM +0100, David Sterba wrote:
> On Thu, Jan 10, 2013 at 10:17:49AM +0800, Liu Bo wrote:
> > Thanks for the report, could you please show me what options you're
> > using?
>
> Default mkfs, mount options 'space_cache,noatime', 40G test partition,
> 10G scratch partit
On Thu, Jan 10, 2013 at 12:54:26PM +0100, David Sterba wrote:
> On Thu, Jan 10, 2013 at 10:05:39AM +0800, Liu Bo wrote:
> > On Tue, Jan 08, 2013 at 12:07:34PM -0800, Zach Brown wrote:
> > > > This is for detecting extent map leak.
> > >
> > > Hmm, I guess it's cool to get the allocation-specific d
We may access and update transaction->abort on the different CPUs without lock,
so we need ACCESS_ONCE() wrapper to make sure we can get the new value.
Signed-off-by: Miao Xie
---
fs/btrfs/super.c | 2 +-
fs/btrfs/transaction.c | 9 -
2 files changed, 5 insertions(+), 6 deletions(-
There is no lock to protect fs_info->fs_state, it will introduce some problems,
such as the value may be covered by the other task when several tasks modify
it. Now we use bit operation for it to fix the above problem.
Signed-off-by: Miao Xie
---
fs/btrfs/ctree.h | 4 +++-
fs/btrfs/disk-io
There is no lock to protect fs_info->avail_{data, metadata, system}_alloc_bits,
it may introduce some problem, such as the wrong profile information, so we add
a seqlock to protect them.
Signed-off-by: Zhao Lei
Signed-off-by: Miao Xie
---
fs/btrfs/ctree.h | 2 ++
fs/btrfs/disk-io.c |
We need not use a global lock to protect the delalloc_bytes of the inode, just
use its own lock. In this way, we can reduce the lock contention and
->delalloc_lock will just protect delalloc inode list.
Signed-off-by: Miao Xie
---
fs/btrfs/btrfs_inode.h | 1 +
fs/btrfs/disk-io.c | 2 ++
fs
fs_info->delalloc_bytes is accessed very frequently, so use percpu counter
instead of the u64 variant for it to reduce the lock contention.
Signed-off-by: Miao Xie
---
fs/btrfs/ctree.h | 7 ---
fs/btrfs/disk-io.c | 18 ++
fs/btrfs/extent-tree.c | 6 --
fs/btrf
->dirty_metadata_bytes is accessed very frequently, so use percpu counter
instead of the u64 variant to reduce the contention of the lock.
Signed-off-by: Miao Xie
---
fs/btrfs/ctree.h | 9
fs/btrfs/disk-io.c | 64
fs/btrfs/exte
fs_info->alloc_start was not protected strictly, it might be changed while
we were accessing it. This patch fixes this problem by using two locks to
protect it (fs_info->chunk_mutex and sb->s_umount). On the read side, we
just need get one of these two locks, and on the write side, we must lock
all
We need not add anything to protect fs_info->max_inline, but we need a comment
to
explain why we don't add a lock to protect it.
Signed-off-by: Miao Xie
---
fs/btrfs/ctree.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 745e7ad..3e672916 100
fs_info->last_trans_log_full_commit is a 64bits variant, we might get a
wrong value on the 32bit machines if we access it directly. Fix it by atomic
operation.
Signed-off-by: Zhao Lei
Signed-off-by: Miao Xie
---
fs/btrfs/ctree.h | 2 +-
fs/btrfs/extent-tree.c | 3 ++-
fs/btrfs/inode.c
fs_info->last_trans_committed is a 64bits variant, we might get a wrong
value on the 32bit machines if we access it directly. Fix it by atomic
operation.
Signed-off-by: Zhao Lei
Signed-off-by: Miao Xie
---
fs/btrfs/ctree.h| 2 +-
fs/btrfs/disk-io.c | 2 +-
fs/btrfs/file.c
fs_info->generation is a 64bit variant, we might get a wrong number on
the 32bit machines if there is no lock or other methods to protect it.
Signed-off-by: Zhao Lei
Signed-off-by: Miao Xie
---
fs/btrfs/ctree.c | 7 ---
fs/btrfs/ctree.h | 2 +-
fs/btrfs/disk-io.c
On Thu, Jan 10, 2013 at 11:38:45AM +1100, Russell Coker wrote:
> The below is from a system running the Debian kernel 3.2.0-4-amd64 on a 120G
> Intel SSD. What would these 2 errors be?
>
> scrub device /dev/disk/by-uuid/7939c405-c656-4e85-a6a0-29f17be09585 (id 1)
> done
> scrub started
On Tue, 11 Dec 2012, Lukas Czerner wrote:
> Date: Tue, 11 Dec 2012 15:24:58 +0100
> From: Lukas Czerner
> To: linux-btrfs@vger.kernel.org
> Cc: chris.ma...@fusionio.com, cwi...@cwillu.com,
> Lukas Czerner
> Subject: [PATCH 1/3] Btrfs-progs: move path modification to filters
>
> Commit 8e8e0
On Thu, Jan 10, 2013 at 10:05:39AM +0800, Liu Bo wrote:
> On Tue, Jan 08, 2013 at 12:07:34PM -0800, Zach Brown wrote:
> > > This is for detecting extent map leak.
> >
> > Hmm, I guess it's cool to get the allocation-specific decoding which you
> > don't get from the generic kernel leak tracking?
>
On Wed, Jan 09, 2013 at 10:43:24PM -0500, Randy Barlow wrote:
> -BEGIN PGP SIGNED MESSAGE-
> > kernel is at 3.6.11-1-ARCH
>
> Sorry I don't know much to help you, but I would suggest perhaps using
> a newer kernel in the future. It sounds like your FS might be in
> trouble as is, but I wou
Signed-off-by: Anand Jain
---
btrfs-list.c | 11 +++
btrfs-list.h |2 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index cb458f1..308b54c 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -1181,6 +1181,17 @@ void btrfs_list_free_filter
Signed-off-by: Anand Jain
---
commands.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/commands.h b/commands.h
index 8114a73..9b77f3e 100644
--- a/commands.h
+++ b/commands.h
@@ -103,3 +103,6 @@ int cmd_qgroup(int argc, char **argv);
/* subvolume exported functions
Signed-off-by: Anand Jain
---
btrfs-list.c | 47 ---
btrfs-list.h | 47 ++-
2 files changed, 46 insertions(+), 48 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index cc065e9..1851f3e 100644
--- a/
Signed-off-by: Anand Jain
---
btrfs-list.c | 37 +
btrfs-list.h |1 +
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index 1851f3e..cb458f1 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -1455,6 +1455,43 @@ in
its better to have btrfs_list_subvols just return witout printing
so that btrfs_list_subvols can be reused.
Signed-off-by: Anand Jain
---
btrfs-list.c | 28 ++--
btrfs-list.h |2 +-
cmds-subvolume.c |4 ++--
3 files changed, 21 insertions(+), 13 deletion
Signed-off-by: Anand Jain
---
btrfs-list.c | 32 +++-
btrfs-list.h |1 +
cmds-subvolume.c |6 +-
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index b656286..cc065e9 100644
--- a/btrfs-list.c
+++ b/btr
Currently we have name prefix (default) and table format to print
the output of subvol list. Just these two formats does not cater
to all the needs, for eg. the up coming show sub-command need a
way to display all the known information of the given subvol.
This patch will provide a way to extend th
This adds show sub-command to the btrfs subvol, which is to display
all known parameters of the given subvol or snapshot. This command
will also list out snapshots of the given subvol if there is any.
Signed-off-by: Anand Jain
---
btrfs-list.c | 25 -
btrfs-list.h |3 +-
cm
On Thu, Jan 10, 2013 at 01:27:33AM +1030, Jordan Windsor wrote:
> [root@archpc btrfs-progs]# ./btrfsck --super 1 /dev/sdb1
> using SB copy 1, bytenr 67108864
> No valid Btrfs found on /dev/sdb1
Please dump the existing superblocks to files and send them to me (they
do not contain any sensitive inf
Signed-off-by: Anand Jain
---
btrfs-list.c |6 ++
btrfs-list.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index 308b54c..efce966 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -1144,6 +1144,11 @@ static int filter_topid_equal(stru
A trivial fix
before this patch
btrfs su list -qu /btrfs
ID 256 gen 35 top level 5 parent UUID - uuid
60e54c4a-8136-3c43-a107-ea42052c6240 path sv1
ID 257 gen 35 top level 5 parent UUID 60e54c4a-8136-3c43-a107-ea42052c6240
uuid fdefa4a9-5b67-4f4c-8a11-c43acec51d43 path ss1
after this path
The definition of the function open_file_or_dir() is moved from common.c
to utils.c in order to be able to share some common code between scrub
and the device stats in the following step. That common code uses
open_file_or_dir(). Since open_file_or_dir() makes use of the function
dirfd(3), the requ
This is an attempt to make btrfs cli more end user friendly.
And adds show subcommand to display all known (as of now)
information of the given subvol including its snapshot(s).
The below patch:
"Btrfs-progs: accommodate different layout for printing subvol list"
obsoletes the previosuly submitte
On Thu, Jan 10, 2013 at 10:17:49AM +0800, Liu Bo wrote:
> Thanks for the report, could you please show me what options you're
> using?
Default mkfs, mount options 'space_cache,noatime', 40G test partition,
10G scratch partition (ie. the same seatup as usual).
I see the free_fs_root warning only 3
On Thu, 10 Jan 2013, Hugo Mills wrote:
>Looks like broken superblocks, from that message. There's probably
> more information in your kernel logs.
The only BTRFS message I see in the kernel log is "btrfs: unlinked 3 orphans"
which happens every time a cron job makes a snapshot of /home. Why
On Wed, Jan 09, 2013 at 10:14:43PM +0100, Goffredo Baroncelli wrote:
> libblkid/src/superblocks/btrfs.c |8
> 1 file changed, 8 insertions(+)
Applied, thanks.
--
Karel Zak
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
On 01/10/2013 04:57 PM, Dan Carpenter wrote:
> The closing parenthesis is in the wrong place. We want to check
> "sizeof(*arg->clone_sources) * arg->clone_sources_count" instead of
> "sizeof(*arg->clone_sources * arg->clone_sources_count)".
>
> Signed-off-by: Dan Carpenter
> ---
> This is also v
The closing parenthesis is in the wrong place. We want to check
"sizeof(*arg->clone_sources) * arg->clone_sources_count" instead of
"sizeof(*arg->clone_sources * arg->clone_sources_count)".
Signed-off-by: Dan Carpenter
---
This is also vulnerable to integer overflows. It's only done under
root,
On Thu, Jan 10, 2013 at 11:38:45AM +1100, Russell Coker wrote:
> The below is from a system running the Debian kernel 3.2.0-4-amd64 on a 120G
> Intel SSD. What would these 2 errors be?
>
> scrub device /dev/disk/by-uuid/7939c405-c656-4e85-a6a0-29f17be09585 (id 1)
> done
> scrub started
Hi Chen,
thanks for reviewing.
I partially disagree with you. The new command(s) is required when the
code detects a change and wants to communicate this change to the
receive side. My patch addresses the cases when
- no new command is required to communicate the change (patch1)
- there is no chan
45 matches
Mail list logo
