Great! Thanks Zach for your quick patch. it works.
Anand
On 05/09/2014 03:45, Zach Brown wrote:
On Thu, Sep 04, 2014 at 07:43:08PM +0800, Anand Jain wrote:
+ static __thread char _str[24];
This patch is causing segmentation fault as it reached maximum stack
depth on
Here is a test case which says it all..
mkfs.xfs -f $DEV
mkfs.btrfs -f $DEV
mount $DEV $MNT
mount: /dev/vdiskc: more filesystems detected. This should not happen,
use -t type to explicitly specify the filesystem type or
use wipefs(8) to clean up the device.
mount: you must specify
On Fri, Jul 04, 2014 at 05:59:06PM +0800, Wang Shilong wrote:
@@ -351,9 +351,9 @@ static int verify_parent_transid(struct extent_io_tree
*io_tree,
- printk_ratelimited(parent transid verify failed on %llu wanted %llu
-found %llu\n,
-eb-start,
When we do a fast fsync, we start all ordered operations and then while
they're running in parallel we visit the list of modified extent maps
and construct their matching file extent items and write them to the
log btree. After that, in btrfs_sync_log() we wait for all the ordered
operations to
Great! Thanks Zach for your quick patch. it works.
Cool.
From 3d132362f4c87b065b63cb38726a030db2277919 Mon Sep 17 00:00:00 2001
From: Zach Brown z...@zabbo.net
Date: Thu, 4 Sep 2014 12:32:00 -0700
Subject: [PATCH] btrfs-progs: use pretty printing macros
David, let me know if you want me
On Wed, Sep 03, 2014 at 10:01:58AM +1000, NeilBrown wrote:
Do we still need maximums at all?
I don't think we do. At least on any system I work with I have to
increase them to get good performance without any adverse effect on
throttling.
So can we just remove the limit on max_sectors and the
On Fri, Sep 05, 2014 at 08:55:01AM -0700, Zach Brown wrote:
David, let me know if you want me to change anything or resend so you
don't have to pull this out of a reply in a thread.
Thanks, I'm now aware of the patch in the thread.
--
To unsubscribe from this list: send the line unsubscribe
Christoph Hellwig h...@infradead.org writes:
On Wed, Sep 03, 2014 at 10:01:58AM +1000, NeilBrown wrote:
Do we still need maximums at all?
I don't think we do. At least on any system I work with I have to
increase them to get good performance without any adverse effect on
throttling.
So
On 09/05/2014 10:40 AM, Jeff Moyer wrote:
Christoph Hellwig h...@infradead.org writes:
On Wed, Sep 03, 2014 at 10:01:58AM +1000, NeilBrown wrote:
Do we still need maximums at all?
I don't think we do. At least on any system I work with I have to
increase them to get good performance
While we're doing a full fsync (when the inode has the flag
BTRFS_INODE_NEEDS_FULL_SYNC set) that is ranged too (covers only a
portion of the file), we might have ordered operations that are started
before or while we're logging the inode and that fall outside the fsync
range.
Therefore when a
This test is motivated by a btrfs issue where a ranged fsync would
prevent a subsequent fsync from persisting any extents that were
dirty at the time of the first fsync but that were outside the range
of that first fsync (which should have been persisted by the second
fsync).
This bug in btrfs is
From: VinÃcius Tinti viniciusti...@gmail.com
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This is the original VLAIS struct.
struct {
struct shash_desc shash;
char ctx[crypto_shash_descsize(tfm)];
} desc;
This patch instead
12 matches
Mail list logo
