On 03/13/2012 02:04 AM, Chris Mason wrote:
On Mon, Mar 12, 2012 at 09:32:54PM +0200, Avi Kivity wrote:
Because I'm such a btrfs fanboi I'm running btrfs on my /, all past
experience notwithstanding. In an attempt to recover some performance,
I enabled autodefrag, and got this in return:
Hi Josef,
On 09.03.2012 17:06, Josef Bacik wrote:
I need to be able to safely deal with refs in my next patch, so convert refs
and
Did I miss your next patch?
pages_reading to ints and introduce an eb_lock spinlock so I can use this to
safely manipulate the refs count when marking eb's as
Hi,
Is anybody using bcache with SSD instead of battery powered raid cards
with Btrfs ?
Hard drives are cheap and big, SSDs are fast but small and expensive.
Wouldn't it be nice if you could transparently get the advantages of
both? With Bcache, you can have your cake and eat it too.
Bcache is
On Tue, Mar 13, 2012 at 10:51:04AM +0100, Jan Schmidt wrote:
Hi Josef,
On 09.03.2012 17:06, Josef Bacik wrote:
I need to be able to safely deal with refs in my next patch, so convert
refs and
Did I miss your next patch?
pages_reading to ints and introduce an eb_lock spinlock so I
Because btrfs cow's we can end up with extent buffers that are no longer
necessary just sitting around in memory. So instead of evicting these pages, we
could end up evicting things we actually care about. Thus we have
free_extent_buffer_stale for use when we are freeing tree blocks. This will
These logs doesn't have the traces of the below BUG_ON().
stack as in the dmesg below has 'btrfs_congested_fn'
which generally notifies block-device near Q full condition.
we would need logs to confirm anything further. was there
a kernel dump generated when BUG_ON was called? that should
I'm not having luck getting the encrypted btrfs back since the drive
the drive was unplugged during a write operation, the experimental
fsck with the repair option gives no valid btrfs found, mount gives
this:
sudo mount -t btrfs /dev/dm-1 /media/
mount: wrong fs type, bad option, bad superblock
I'm sorry but I don't know how to get the kernel dump. It seems that
the kernel dump is not enabled for my kernel:
# CONFIG_CRASH_DUMP is not set
On 3/13/12, Anand Jain anand.j...@oracle.com wrote:
These logs doesn't have the traces of the below BUG_ON().
stack as in the dmesg below has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/16/2012 12:58 PM, Chris Mason wrote:
On Thu, Feb 16, 2012 at 07:55:15PM +0600, Roman Mamedov wrote:
Hello,
Please be aware that there seems to be a possible problem with
using NOCOW flag on files situated on a filesystem mounted with
These information might be useful:
$sudo btrfsck /home/not-a-user/broken-btrfs.img
bad block 29933568
bad block 44224512
parent transid verify failed on 54566912 wanted 3532 found 3475
parent transid verify failed on 54566912 wanted 3532 found 3475
Extent back ref already exists for 40439808
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/13/2012 02:11 PM, Jeff Mahoney wrote:
On 02/16/2012 12:58 PM, Chris Mason wrote:
On Thu, Feb 16, 2012 at 07:55:15PM +0600, Roman Mamedov wrote:
Hello,
Please be aware that there seems to be a possible problem with
using NOCOW flag on
On 3/9/2012 11:48 PM, Ted Ts'o wrote:
I suspect the best optimization for now is probably something like
this:
1) Since the vast majority of directories are less than (say) 256k
(this would be a tunable value), for directories which are less than
this threshold size, the entire directory is
On Tue, Mar 13, 2012 at 03:05:59PM -0400, Phillip Susi wrote:
Why not just separate the hash table from the conventional, mostly
in inode order directory entries? For instance, the first 200k of
the directory could be the normal entries that would tend to be in
inode order ( and e2fsck -D
On 3/13/2012 3:53 PM, Ted Ts'o wrote:
Because that would be a format change.
I think a format change would be preferable to runtime sorting.
What we have today is not a hash table; it's a hashed tree, where we
use a fixed-length key for the tree based on the hash of the file
name. Currently
Before commit a46e7ff2 was merged it was possible to create dup for
data+metadata chunks (mixed mode) by giving -m raid1 -d raid1 -M to
mkfs. a46e7ff2 purposefully disabled behind the scenes profile
upgrading/downgrading, so give users a chance to pick dup explicitly and
bail if dup for data is
This adds proper formatting for free space and inode cache items in
btrfs-debug-tree output.
Signed-off-by: Ilya Dryomov idryo...@gmail.com
---
ctree.h | 29 +
print-tree.c | 52 +++-
2 files changed, 72
On Tue, Mar 13, 2012 at 04:22:52PM -0400, Phillip Susi wrote:
I think a format change would be preferable to runtime sorting.
Are you volunteering to spearhead the design and coding of such a
thing? Run-time sorting is backwards compatible, and a heck of a lot
easier to code and test...
The
What if we use inode number as the hash value? Does it work?
Yongqiang.
--
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://vger.kernel.org/majordomo-info.html
On Wed, Mar 14, 2012 at 10:48:17AM +0800, Yongqiang Yang wrote:
What if we use inode number as the hash value? Does it work?
The whole point of using the tree structure is to accelerate filename
- inode number lookups. So the namei lookup doesn't have the inode
number; the whole point is to
$sudo btrfsck /home/not-a-user/broken-btrfs.img
bad block 29933568
bad block 44224512
parent transid verify failed on 54566912 wanted 3532 found 3475
These aren't related to the original problem as in the subject.
But it could be the panic's aftermath effect if IOs didn't made
into the
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/ctree.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 80b6486..a515e4e 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -597,9 +597,9 @@ struct
21 matches
Mail list logo
