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 anand.j...@oracle.com
On 06/28/2013 01:49 AM, Josef Bacik wrote:
There are a
On Fri, Jun 28, 2013 at 01:15:52PM +0800, Jeff Liu wrote:
From: Jie Liu jeff@oracle.com
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
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 jeff@oracle.com
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
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 jeff@oracle.com
Create a small file and fallocate it to a big size with
FALLOC_FL_KEEP_SIZE option, then
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.
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 about x8 the
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 both data and
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:
The second disk
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
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:
Using two equal
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
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
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, Martin
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
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 jeff@oracle.com
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,
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 jeff@oracle.com
Create a small file and fallocate it to a big size with
FALLOC_FL_KEEP_SIZE option, then
18 matches
Mail list logo
