Looks good. But. Since there is repeated calls to mkfs,
-f option might be mandatory. and 265 is indeed working before.
You need to re-phrase the title to the fixes you are bringing in.
Reviewed-by: Anand Jain
On 06/28/2013 01:49 AM, Josef Bacik wrote:
There are a few problems with btr
On Fri, Jun 28, 2013 at 01:15:52PM +0800, Jeff Liu wrote:
> From: Jie Liu
>
> Create a small file and fallocate it to a big size with
> FALLOC_FL_KEEP_SIZE option, then truncate it back to the
> small size again, the disk free space is not changed back
> in this case. i.e,
>
> # dd if=/dev/zero
On 06/28/2013 08:41 PM, Josef Bacik wrote:
> On Fri, Jun 28, 2013 at 01:15:52PM +0800, Jeff Liu wrote:
>> From: Jie Liu
>>
>> Create a small file and fallocate it to a big size with
>> FALLOC_FL_KEEP_SIZE option, then truncate it back to the
>> small size again, the disk free space is not changed
On Fri, Jun 28, 2013 at 09:07:49PM +0800, Jeff Liu wrote:
> On 06/28/2013 08:41 PM, Josef Bacik wrote:
>
> > On Fri, Jun 28, 2013 at 01:15:52PM +0800, Jeff Liu wrote:
> >> From: Jie Liu
> >>
> >> Create a small file and fallocate it to a big size with
> >> FALLOC_FL_KEEP_SIZE option, then truncat
On kernel 3.8.13:
Using two equal performance SATAII HDDs, formatted for btrfs raid1 for
both data and metadata and:
The second disk appears to suffer about x8 the read activity of the
first disk. This causes the second disk to quickly get maxed out whilst
the first disk remains almost idle.
Tot
On Fri, Jun 28, 2013 at 02:59:45PM +0100, Martin wrote:
> On kernel 3.8.13:
>
> Using two equal performance SATAII HDDs, formatted for btrfs raid1 for
> both data and metadata and:
>
> The second disk appears to suffer about x8 the read activity of the
> first disk. This causes the second disk to
On Fri, Jun 28, 2013 at 11:34:18AM -0400, Josef Bacik wrote:
> On Fri, Jun 28, 2013 at 02:59:45PM +0100, Martin wrote:
> > On kernel 3.8.13:
> >
> > Using two equal performance SATAII HDDs, formatted for btrfs raid1 for
> > both data and metadata and:
> >
> > The second disk appears to suffer abo
Hugo Mills posted on Fri, 28 Jun 2013 16:39:10 +0100 as excerpted:
> On Fri, Jun 28, 2013 at 11:34:18AM -0400, Josef Bacik wrote:
>> On Fri, Jun 28, 2013 at 02:59:45PM +0100, Martin wrote:
>> > On kernel 3.8.13:
>> >
>> > Using two equal performance SATAII HDDs, formatted for btrfs raid1
>> > for
On 28/06/13 16:39, Hugo Mills wrote:
> On Fri, Jun 28, 2013 at 11:34:18AM -0400, Josef Bacik wrote:
>> On Fri, Jun 28, 2013 at 02:59:45PM +0100, Martin wrote:
>>> On kernel 3.8.13:
>>>
>>> Using two equal performance SATAII HDDs, formatted for btrfs
>>> raid1 for both data and metadata and:
>>>
>
On 06/28/2013 09:25 AM, Martin wrote:
On 28/06/13 16:39, Hugo Mills wrote:
On Fri, Jun 28, 2013 at 11:34:18AM -0400, Josef Bacik wrote:
On Fri, Jun 28, 2013 at 02:59:45PM +0100, Martin wrote:
On kernel 3.8.13:
Using two equal performance SATAII HDDs, formatted for btrfs
raid1 for both data an
On Fri, Jun 28, 2013 at 09:55:31AM -0700, George Mitchell wrote:
> On 06/28/2013 09:25 AM, Martin wrote:
> >On 28/06/13 16:39, Hugo Mills wrote:
> >>On Fri, Jun 28, 2013 at 11:34:18AM -0400, Josef Bacik wrote:
> >>>On Fri, Jun 28, 2013 at 02:59:45PM +0100, Martin wrote:
> On kernel 3.8.13:
> >>
On Fri, Jun 28, 2013 at 10:25:39AM +0800, Liu Bo wrote:
> Several users reported this crash of NULL pointer or general protection,
> the story is that we add a rbtree for speedup ulist iteration, and we
> use krealloc() to address ulist growth, and krealloc() use memcpy to copy
> old data to new me
I missed fixing the backref stuff when I introduced the skinny metadata. If you
try and do things like snapshot aware defrag with skinny metadata you are going
to see tons of warnings related to the backref count being less than 0. This is
because the delayed refs will be found for stuff just fin
On Thu, Jun 27, 2013 at 02:33:20PM -0700, Zach Brown wrote:
> Reviewing as requested! It certainly looks reasonable, but I don't have
> enough history with the code to really say much more than that.
>
> Some questions:
>
> > @@ -8423,6 +8432,10 @@ void btrfs_create_pending_block_groups(struct
On 28/06/13 18:04, Josef Bacik wrote:
> On Fri, Jun 28, 2013 at 09:55:31AM -0700, George Mitchell wrote:
>> On 06/28/2013 09:25 AM, Martin wrote:
>>> On 28/06/13 16:39, Hugo Mills wrote:
On Fri, Jun 28, 2013 at 11:34:18AM -0400, Josef Bacik wrote:
> On Fri, Jun 28, 2013 at 02:59:45PM +0100
On Fri, Jun 28, 2013 at 12:37:45PM +0800, Liu Bo wrote:
> Several users reported this crash of NULL pointer or general protection,
> the story is that we add a rbtree for speedup ulist iteration, and we
> use krealloc() to address ulist growth, and krealloc() use memcpy to copy
> old data to new me
On Fri, Jun 28, 2013 at 08:41:00AM -0400, Josef Bacik wrote:
> On Fri, Jun 28, 2013 at 01:15:52PM +0800, Jeff Liu wrote:
> > From: Jie Liu
> >
> > Create a small file and fallocate it to a big size with
> > FALLOC_FL_KEEP_SIZE option, then truncate it back to the
> > small size again, the disk fr
On 06/29/2013 10:22 AM, Dave Chinner wrote:
> On Fri, Jun 28, 2013 at 08:41:00AM -0400, Josef Bacik wrote:
>> On Fri, Jun 28, 2013 at 01:15:52PM +0800, Jeff Liu wrote:
>>> From: Jie Liu
>>>
>>> Create a small file and fallocate it to a big size with
>>> FALLOC_FL_KEEP_SIZE option, then truncate i
18 matches
Mail list logo
