On Fri, Jan 20, 2012 at 10:48 AM, Vincent Vanackere
wrote:
> On 01/19/2012 05:24 PM, Mitch Harder wrote:
>>
>> On Thu, Jan 19, 2012 at 8:42 AM, Vincent Vanackere
>> wrote:
>>>
>>> Hi,
>>>
>>> With the most current git kernel
>>> (90a4c0f51e8e44111a926be6f4c87af3938a79c3)
>>> I'm still getting th
On Wed, Jan 18, 2012 at 5:13 PM, Mitch Harder
wrote:
> I have a Btrfs partition that is reliably reproducing premature ENOSPC
> when restoring the disk from a tar file, but it is only happening with
> zlib compression (lzo or no compression proceeds normally).
thank you very much for this info.
On 01/19/2012 05:24 PM, Mitch Harder wrote:
On Thu, Jan 19, 2012 at 8:42 AM, Vincent Vanackere
wrote:
Hi,
With the most current git kernel (90a4c0f51e8e44111a926be6f4c87af3938a79c3)
I'm still getting the same reproducible kernel panic when trying to read a
particular file stored on a btrfs fi
On Fri, Jan 20, 2012 at 06:21:29PM +0300, Dan Carpenter wrote:
> On Fri, Jan 20, 2012 at 04:24:37PM +0200, Ilya Dryomov wrote:
> > --- a/fs/btrfs/volumes.c
> > +++ b/fs/btrfs/volumes.c
> > @@ -2375,12 +2375,11 @@ static int should_balance_chunk(struct btrfs_root
> > *root,
> > struct btrfs_bal
On Fri, Jan 20, 2012 at 04:24:37PM +0200, Ilya Dryomov wrote:
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -2375,12 +2375,11 @@ static int should_balance_chunk(struct btrfs_root
> *root,
> struct btrfs_balance_control *bctl = root->fs_info->balance_ctl;
> struct btrfs_bal
On Fri, Jan 20, 2012 at 10:54:55AM +0300, Dan Carpenter wrote:
> The intent here was to do a logical && instead of a bitwise &. The
> original condition tests whether they have the some of same bits set.
> I have fixed that and rewritten it to be more clear.
>
> Signed-off-by: Dan Carpenter
> --
On Fri, Jan 20, 2012 at 2:19 AM, Fajar A. Nugraha wrote:
> Then again, most fsck feature has been implemented in kernel space so
> a mount will automatically "fix" some types of problems (somewhat
> similar to what zfs does, which has no fsck whatsoever). So just watch
> syslog for any unusual err
As you might know, I have been seeing btrfs slowdowns in our ceph
cluster for quite some time. Even with the latest btrfs code for 3.3
I'm still seeing these problems. To make things reproducible, I've now
written a small test, that imitates ceph's behavior:
On a freshly created btrfs filesystem (
On 19.01.2012 06:58, Miao Xie wrote:
> Onwed, 18 Jan 2012 11:12:20 +0100, Jan Schmidt wrote:
>> On 17.01.2012 21:58, Chris Mason wrote:
>>> These two didn't make my first pull request just because I wanted to get
>>> something out the door. I'll definitely have them in the next pull.
>>
>> Ple
