On thu, 18 Jul 2013 23:46:10 -0700, Filipe David Borba Manana wrote:
> Signed-off-by: Filipe David Borba Manana
> ---
> extent-tree.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/extent-tree.c b/extent-tree.c
> index f597e16..8e93bab 100644
> --- a/extent-tree.c
> +++ b/extent-t
Instead the spinlock super_lock looks appropriate for
protecting concurrent access to the label field of fs_info->super_copy.
In btrfs_ioctl_set_fslabel() make sure to only hold the spinlock for the
copy operation, not while calling the transaction functions.
Oh yeah ! fs_info->super_lock is
btrfs_ioctl_get_fslabel() and btrfs_ioctl_set_fslabel()
used root->fs_info->volume_mutex mutex which caused operations
like balance to block set/get label operation until its
completion and generally balance operation takes a long
time to complete, so it will be annoying to the user when
cli appear
Hello,
I'm playing the role of Chris Mason this week while he's on vacation. There are
a few critical fixes for btrfs here, all regressions and have been tested well.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git for-linus
I've based it off a recent pull of
On Thu, Jul 11, 2013 at 12:26:50AM +0200, David Sterba wrote:
> On Wed, Jul 10, 2013 at 10:45:45AM -0700, Mark Fasheh wrote:
> > Well, what do I get when I pretend I don't care any more? The little voice
> > in my head says "keep plugging away". Here's another attempt at fixing this
> > problem in
I'm using 3.10 with a btrfs filesystem with RAID-1 (on two drives),
with extended inode refs and skinny metadata extent refs enabled (-r
and -x options in btrfstune).
Server has 32 GB RAM.
Filesystem is mounted with noatime,compress-force=zlib mount options.
btrfs performs really, really poor w
