On Wed, Sep 23, 2015 at 10:00:12PM +0800, Qu Wenruo wrote:
> As it's already planned, and I think it will need new incompact flag
> anyway, or old kernel can easily remove/convert desired profile.
The usecase with the old kernel is colser to the rescue scenario than
regular use. We do have suppor
On Wed, Sep 23, 2015 at 03:28:29PM +0200, David Sterba wrote:
> On Tue, Sep 22, 2015 at 03:39:30PM +, Hugo Mills wrote:
> > > The way I would expect things to work is that a new subvolume
> > > inherits it's properties from it's parent (if it's a snapshot),
> >
> >Definitely this.
> >
> >
在 2015年09月23日 21:32, Austin S Hemmelgarn 写道:
On 2015-09-23 09:19, Qu Wenruo wrote:
在 2015年09月23日 21:12, David Sterba 写道:
On Tue, Sep 22, 2015 at 02:36:02PM +, Hugo Mills wrote:
Yeah, right now there's no persistent default for the allocator. I'm
still hoping that the object properties
On 2015-09-23 09:28, David Sterba wrote:
On Tue, Sep 22, 2015 at 03:39:30PM +, Hugo Mills wrote:
The way I would expect things to work is that a new subvolume
inherits it's properties from it's parent (if it's a snapshot),
Definitely this.
or
from the next higher subvolume it's neste
On Wed, Sep 23, 2015 at 09:19:38PM +0800, Qu Wenruo wrote:
> 在 2015年09月23日 21:12, David Sterba 写道:
> >On Tue, Sep 22, 2015 at 02:36:02PM +, Hugo Mills wrote:
> >>>Yeah, right now there's no persistent default for the allocator. I'm
> >>>still hoping that the object properties will magically sol
On Wed, Sep 23, 2015 at 09:19:38PM +0800, Qu Wenruo wrote:
> > From the UI point, we proposed to add a specifier that would route the
> > property to either subvolume or the filesystem:
> >
> > $ btrfs prop set -t filesystem bgtype raid0
> > $ btrfs prop set -t subvolume bgtype raid1
>
> BTW, is
On 2015-09-23 09:19, Qu Wenruo wrote:
在 2015年09月23日 21:12, David Sterba 写道:
On Tue, Sep 22, 2015 at 02:36:02PM +, Hugo Mills wrote:
Yeah, right now there's no persistent default for the allocator. I'm
still hoping that the object properties will magically solve that.
There's no obvi
On Tue, Sep 22, 2015 at 03:39:30PM +, Hugo Mills wrote:
> > The way I would expect things to work is that a new subvolume
> > inherits it's properties from it's parent (if it's a snapshot),
>
>Definitely this.
>
> > or
> > from the next higher subvolume it's nested in.
>
>I don't thi
On Wed, Sep 23, 2015 at 03:12:26PM +0200, David Sterba wrote:
> On Tue, Sep 22, 2015 at 02:36:02PM +, Hugo Mills wrote:
> > > Yeah, right now there's no persistent default for the allocator. I'm
> > > still hoping that the object properties will magically solve that.
> >
> >There's no obvi
在 2015年09月23日 21:12, David Sterba 写道:
On Tue, Sep 22, 2015 at 02:36:02PM +, Hugo Mills wrote:
Yeah, right now there's no persistent default for the allocator. I'm
still hoping that the object properties will magically solve that.
There's no obvious place that filesystem-wide properti
On Tue, Sep 22, 2015 at 02:36:02PM +, Hugo Mills wrote:
> > Yeah, right now there's no persistent default for the allocator. I'm
> > still hoping that the object properties will magically solve that.
>
>There's no obvious place that filesystem-wide properties can be
> stored, though. There
Austin S Hemmelgarn posted on Tue, 22 Sep 2015 13:32:58 -0400 as
excerpted:
>> Of course, you shouldn't be nesting subvolumes anyway. It makes
>> it much harder to manage them.
>
> That depends though, I only ever do single nesting (ie, a subvolume in a
> subvolume), and I use it to exclude stuff
Hi, Jeff Mahoney
> -Original Message-
> From: Jeff Mahoney [mailto:je...@suse.com]
> Sent: Tuesday, September 22, 2015 9:00 PM
> To: Zhao Lei ; linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH] btrfs: Fix no space bug caused by removing bg
>
> -BEGIN PGP SIGNE
Hi, Filipe David Manana
> -Original Message-
> At the very least this patch should have its title and description changed -
> to
> reflect that it attempts to solve only (and partially) the problem of losing
> raid
> profile type.
>
When I found the bug in testing v4.3-rc1, the only erro
On 2015-09-22 13:32, Austin S Hemmelgarn wrote:
On 2015-09-22 11:39, Hugo Mills wrote:
On Tue, Sep 22, 2015 at 10:54:45AM -0400, Austin S Hemmelgarn wrote:
On 2015-09-22 10:36, Hugo Mills wrote:
On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote:
On Tue, Sep 22, 2015 at 01:41:31PM +
On 2015-09-22 11:39, Hugo Mills wrote:
On Tue, Sep 22, 2015 at 10:54:45AM -0400, Austin S Hemmelgarn wrote:
On 2015-09-22 10:36, Hugo Mills wrote:
On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote:
On Tue, Sep 22, 2015 at 01:41:31PM +, Hugo Mills wrote:
On Tue, Sep 22, 2015 at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/22/15 9:36 AM, Holger Hoffstätte wrote:
> On 09/22/15 14:59, Jeff Mahoney wrote: (snip)
>> So if they way we want to prevent the loss of raid type info is
>> by maintaining the last block group allocated with that raid
>> type, fine, but that's a
On Tue, Sep 22, 2015 at 10:54:45AM -0400, Austin S Hemmelgarn wrote:
> On 2015-09-22 10:36, Hugo Mills wrote:
> >On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote:
> >>On Tue, Sep 22, 2015 at 01:41:31PM +, Hugo Mills wrote:
> >>>On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger Hoffst
On 2015-09-22 10:36, Hugo Mills wrote:
On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote:
On Tue, Sep 22, 2015 at 01:41:31PM +, Hugo Mills wrote:
On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger Hoffstätte wrote:
On 09/22/15 14:59, Jeff Mahoney wrote:
(snip)
So if they way we w
On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote:
> On Tue, Sep 22, 2015 at 01:41:31PM +, Hugo Mills wrote:
> > On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger Hoffstätte wrote:
> > > On 09/22/15 14:59, Jeff Mahoney wrote:
> > > (snip)
> > > > So if they way we want to prevent the
On Tue, Sep 22, 2015 at 01:41:31PM +, Hugo Mills wrote:
> On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger Hoffstätte wrote:
> > On 09/22/15 14:59, Jeff Mahoney wrote:
> > (snip)
> > > So if they way we want to prevent the loss of raid type info is by
> > > maintaining the last block group allo
On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger Hoffstätte wrote:
> On 09/22/15 14:59, Jeff Mahoney wrote:
> (snip)
> > So if they way we want to prevent the loss of raid type info is by
> > maintaining the last block group allocated with that raid type, fine,
> > but that's a separate discussion.
On 09/22/15 14:59, Jeff Mahoney wrote:
(snip)
> So if they way we want to prevent the loss of raid type info is by
> maintaining the last block group allocated with that raid type, fine,
> but that's a separate discussion. Personally, I think keeping 1GB
At this point I'm much more surprised to l
On Tue, Sep 22, 2015 at 08:59:57AM -0400, Jeff Mahoney wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
[snip]
> So if they way we want to prevent the loss of raid type info is by
> maintaining the last block group allocated with that raid type, fine,
> but that's a separate discussion. Pe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/21/15 8:59 AM, Zhao Lei wrote:
> btrfs in v4.3-rc1 failed many xfstests items with '-o
> nospace_cache' mount option.
>
> Failed cases are:
> btrfs/008,016,019,020,026,027,028,029,031,041,046,048,050,051,053,054,
>
>
077,083,084,087,092,094
> g
6:22 PM
>> To: Zhao Lei
>> Cc: linux-btrfs@vger.kernel.org
>> Subject: Re: [PATCH] btrfs: Fix no space bug caused by removing bg
>>
>> On Tue, Sep 22, 2015 at 11:06 AM, Zhao Lei wrote:
>> > Hi, Filipe David Manana
>> >
>> > Thanks for r
mailto:fdman...@gmail.com]
> >> Sent: Monday, September 21, 2015 9:27 PM
> >> To: Zhao Lei
> >> Cc: linux-btrfs@vger.kernel.org
> >> Subject: Re: [PATCH] btrfs: Fix no space bug caused by removing bg
> >>
> >> On Mon, Sep 21, 2015 at
> > To: Zhao Lei
> > Cc: linux-btrfs@vger.kernel.org
> > Subject: Re: [PATCH] btrfs: Fix no space bug caused by removing bg
> >
> > On Mon, Sep 21, 2015 at 1:59 PM, Zhao Lei wrote:
> > > btrfs in v4.3-rc1 failed many xfstests item
>> Cc: linux-btrfs@vger.kernel.org
>> Subject: Re: [PATCH] btrfs: Fix no space bug caused by removing bg
>>
>> On Mon, Sep 21, 2015 at 1:59 PM, Zhao Lei wrote:
>> > btrfs in v4.3-rc1 failed many xfstests items with '-o nos
Hi, Filipe David Manana
Thanks for review this patch.
> -Original Message-
> From: Filipe David Manana [mailto:fdman...@gmail.com]
> Sent: Monday, September 21, 2015 9:27 PM
> To: Zhao Lei
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH] btrfs: Fix no s
On Mon, Sep 21, 2015 at 2:27 PM, Filipe David Manana wrote:
> On Mon, Sep 21, 2015 at 1:59 PM, Zhao Lei wrote:
>> btrfs in v4.3-rc1 failed many xfstests items with '-o nospace_cache'
>> mount option.
>>
>> Failed cases are:
>> btrfs/008,016,019,020,026,027,028,029,031,041,046,048,050,051,053,054
On Mon, Sep 21, 2015 at 1:59 PM, Zhao Lei wrote:
> btrfs in v4.3-rc1 failed many xfstests items with '-o nospace_cache'
> mount option.
>
> Failed cases are:
> btrfs/008,016,019,020,026,027,028,029,031,041,046,048,050,051,053,054,
> 077,083,084,087,092,094
Hi Zhao,
So far I tried a few of thos
btrfs in v4.3-rc1 failed many xfstests items with '-o nospace_cache'
mount option.
Failed cases are:
btrfs/008,016,019,020,026,027,028,029,031,041,046,048,050,051,053,054,
077,083,084,087,092,094
generic/004,010,014,023,024,074,075,080,086,087,089,091,092,100,112,123,
124,125,126,127,131,133,1
33 matches
Mail list logo
