On 11/06/2014 10:57 AM, Chris Murphy wrote:
Summary: After successfully completed btrfs replace start, btrfs fi show lists
the old devid size not the new devid size.
kernel-3.17.2-300.fc21.x86_64
btrfs-progs-3.17-1.fc21.x86_64
##Before devid2 is missing (normal mount of 2x HDDs, raw block d
On 11/06/2014 09:51 AM, Qu Wenruo wrote:
Original Message
Subject: Re: Compatibility matrix kernel/tools
From: Hugo Mills
To: Cyril Scetbon
Date: 2014年11月06日 05:45
On Wed, Nov 05, 2014 at 09:57:31PM +0100, Cyril Scetbon wrote:
Hi,
Where can I find the compatibility matri
On Nov 5, 2014, at 8:28 PM, Chris Murphy wrote:
> Filed a bug. The btrfs fi show, and (conventional) df command are the same
> with kernel-3.18.0-0.rc3.git0.1.fc22.x86_64
> https://bugzilla.kernel.org/show_bug.cgi?id=87851
>
> I'm going to guess this is a btrfs-progs bug not resizing the file
Filed a bug. The btrfs fi show, and (conventional) df command are the same with
kernel-3.18.0-0.rc3.git0.1.fc22.x86_64
https://bugzilla.kernel.org/show_bug.cgi?id=87851
I'm going to guess this is a btrfs-progs bug not resizing the file system to
"max"; I'm pretty sure this was working at one tim
Summary: After successfully completed btrfs replace start, btrfs fi show lists
the old devid size not the new devid size.
kernel-3.17.2-300.fc21.x86_64
btrfs-progs-3.17-1.fc21.x86_64
##Before devid2 is missing (normal mount of 2x HDDs, raw block devices are
formatted, no partitioning)
#btrfs
ping.
Any comments?
Original Message
Subject: [PATCH 2/2] btrfs: Add support for nocow write into prealloc
space with compression
From: Qu Wenruo
To:
Date: 2014年09月18日 12:01
**
* WARNING: on-disk data format changes is int
Original Message
Subject: Re: Compatibility matrix kernel/tools
From: Hugo Mills
To: Cyril Scetbon
Date: 2014年11月06日 05:45
On Wed, Nov 05, 2014 at 09:57:31PM +0100, Cyril Scetbon wrote:
Hi,
Where can I find the compatibility matrix to know which btrfs-tools version
should
oh cool to know !
It's weird that the man page says "limits are never enforced on the superuser
(nor are they enforced for group and project ID zero)"
http://manpages.ubuntu.com/manpages/trusty/en/man8/xfs_quota.8.html
Thanks
--
Cyril SCETBON
> On 02 Nov 2014, at 22:48, Chris Murphy wrote:
>
On Wed, Nov 05, 2014 at 09:57:31PM +0100, Cyril Scetbon wrote:
> Hi,
>
> Where can I find the compatibility matrix to know which btrfs-tools version
> should work with a chosen linux kernel ?
Any of them should work with any kernel.
For normal operation, if the tools are too old, they may
Hi,
Where can I find the compatibility matrix to know which btrfs-tools version
should work with a chosen linux kernel ?
--
Cyril SCETBON
--
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 11/05/2014 04:03 PM, Filipe David Manana wrote:
On Wed, Nov 5, 2014 at 8:33 PM, Josef Bacik wrote:
On 11/05/2014 02:56 PM, Filipe Manana wrote:
We have a race while deleting unused block groups that causes extents
written
by past generations/transactions to be rewritten by the current
tran
From: Christoph Hellwig
Clean up the generic_write_sync by just passing an iocb and a bytes
written / negative errno argument. In addition to simplifying the
callers this also prepares for passing a per-operation O_DSYNC
flag. Two callers didn't quite fit that scheme:
- dio_complete didn't bo
On Wed, Nov 5, 2014 at 8:33 PM, Josef Bacik wrote:
> On 11/05/2014 02:56 PM, Filipe Manana wrote:
>>
>> We have a race while deleting unused block groups that causes extents
>> written
>> by past generations/transactions to be rewritten by the current
>> transaction
>> before that transaction is c
On 11/05/2014 02:56 PM, Filipe Manana wrote:
We have a race while deleting unused block groups that causes extents written
by past generations/transactions to be rewritten by the current transaction
before that transaction is committed. The steps that lead to this issue:
1) At transaction N one
On 11/05/2014 02:56 PM, Filipe Manana wrote:
We have a race while deleting unused block groups that causes extents written
by past generations/transactions to be rewritten by the current transaction
before that transaction is committed. The steps that lead to this issue:
1) At transaction N one
We have a race while deleting unused block groups that causes extents written
by past generations/transactions to be rewritten by the current transaction
before that transaction is committed. The steps that lead to this issue:
1) At transaction N one or more block groups became unused and we added
16 matches
Mail list logo