Re: ext3/jbd oops in journal_start

On Sat, 31 Oct 2009, Dmitry Monakhov wrote: > Sage Weil writes: > > > Hi, > > > > I'm consistently seeing ext3 oops on a fresh ~60 GB fs on 2.6.32-rc3 (and > > 2.6.31). data=writeback or data=ordered. It's not the hardware or > > drive... I have 8 boxes (each with slightly different hardware

Re: [patch 2/2] grub-0.97: btrfs multidevice configuration support

Johannes Hirte wrote: Am Freitag 25 September 2009 00:06:40 schrieb Edward Shishkin: Hi Edward, I was pointed to a problem with this patch. +static u64 scan_grub_devices(struct btrfs_device *dev, +int (*discerner)(struct btrfs_device **, int), +

Re: announcement of deduplication in Sun ZFS

I don't think ZFS has any goals of being resilient to errors as far as recovering from them without backups / redundant disks Errors would still be detected though more data of course would be unavailable potentially. On Nov 2, 2009, at 6:04 PM, Chris Samuel wrote: On Tue, 3 Nov 2009 0

Re: announcement of deduplication in Sun ZFS

On Mon, Nov 2, 2009 at 3:04 PM, Chris Samuel wrote: > On Tue, 3 Nov 2009 07:51:52 am Alex Dedul wrote: > > > In any way thats a nice and interesting feature, thanks! :) > > My concern would be that it increases the impact of a corruption of the block > that has been de-dup'd - in other words if th

Re: announcement of deduplication in Sun ZFS

On Tue, 3 Nov 2009 07:51:52 am Alex Dedul wrote: > In any way thats a nice and interesting feature, thanks! :) My concern would be that it increases the impact of a corruption of the block that has been de-dup'd - in other words if the block that now represents the same data in lots of files ge

Re: [patch 2/2] grub-0.97: btrfs multidevice configuration support

Am Freitag 25 September 2009 00:06:40 schrieb Edward Shishkin: > Hi Edward, I was pointed to a problem with this patch. +static u64 scan_grub_devices(struct btrfs_device *dev, +int (*discerner)(struct btrfs_device **, int), +int lookup) +{

Re: btrfsck aborts after transid verify failed?

On Tue, Oct 27, 2009 at 11:23:43PM +0100, Johannes Hirte wrote: > Am Montag 26 Oktober 2009 10:41:04 schrieb Chris Mason: > > > On 10/21/2009 09:44 AM, Yan, Zheng wrote: > > > >On Wed, Oct 21, 2009 at 9:21 PM, John Dong wrote: > > > >>> On Oct 21, 2009, at 3:47 AM, Yan, Zheng wrote: > > > >

Implement the incremental backup

Hello, I was interested in working on the incremental backup requirements as listed on the wiki (http://btrfs.wiki.kernel.org/index.php/Project_ideas#Incremental_backups), is this project still open? If so can someone please be my initial mentor? Regards, Nikhil -- To unsubscribe from this lis

Re: announcement of deduplication in Sun ZFS

Hi! > Is it inappropriate to post a relevant news item to this list? Please > correct me off-list if so. > > http://blogs.sun.com/bonwick/en_US/entry/zfs_dedup In any way thats a nice and interesting feature, thanks! :) With best regards from the Soul, Alex. -- To unsubscribe from this list: sen

announcement of deduplication in Sun ZFS

Is it inappropriate to post a relevant news item to this list? Please correct me off-list if so. http://blogs.sun.com/bonwick/en_US/entry/zfs_dedup -- 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

[PATCH] Btrfs: find ideal block group for caching

This patch changes a few things. Hopefully the comments are helpfull, but I'll try and be as verbose here. Problem: My fedora box was taking 1 minute and 21 seconds to boot with btrfs as root. Part of this problem was we pick the first block group we can find and start caching it, even if it may

[PATCH 2/3] Btrfs: fix data allocation hint start

Sometimes our start allocation hint when we cow a file can be either EXTENT_HOLE or some other such place holder, which is not optimal. So if we find that our em->block_start is one of these special values, check to see where the first block of the inode is stored, and use that as a hint. If that

[PATCH] Btrfs: Fix cluster window start

We use cluster->window_start as a hint of where to find the block group for our allocation. The problem is we also use this offset as a minimum starting offset when we look through our cluster for allocations. So what happens is we end up setting this offset to whatever the last entry we found wa

Re: Kernel [BUG] trace on suspend.

On Fri, Oct 30, 2009 at 08:26:12PM +0300, Michael Raskin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Attached find a dmesg snapshot. Configuration: Zen-kernel 2.6.31-zen5 > with TuxOnIce and BtrFS, suspend from console. > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.1

Re: [PATCH 12/27] BKL: Remove BKL from btrfs

On Mon, Nov 02, 2009 at 11:04:52AM +0100, Jan Blunck wrote: > BKL is only used in get_sb. It is safe to remove it. > > Signed-off-by: Jan Blunck Acked-by: Chris Mason Thanks! -chris > --- > fs/btrfs/super.c |8 +--- > 1 files changed, 1 insertions(+), 7 deletions(-) > > diff --git

[PATCH 12/27] BKL: Remove BKL from btrfs

BKL is only used in get_sb. It is safe to remove it. Signed-off-by: Jan Blunck --- fs/btrfs/super.c |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index e5cd2cf..752a546 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -

[PATCH 8/8] Make truncate(2) more ENOSPC friendly

truncating and deleting regular file are unbound operations, so it's not good to do them in a single transaction. This patch makes btrfs_truncate and btrfs_delete_inode start a new transaction after all items in a tree leaf are deleted. Signed-off-by: Yan Zheng --- diff -urp 7/fs/btrfs/inode.c 8

[PATCH 7/8] Make fallocate(2) more ENOSPC friendly

fallocate(2) may allocate large number of file extents, so it's not good to do it in a single transaction. This patch make fallocate(2) start a new transaction for each file extents it allocates. Signed-off-by: Yan Zheng --- diff -urp 6/fs/btrfs/inode.c 7/fs/btrfs/inode.c --- 6/fs/btrfs/inode.c

[PATCH 4/8] Fix disk_i_size update corner case.

There are some cases file extents are inserted without involving ordered struct. In these cases, we update disk_i_size directly, without checking pending ordered extent and DELALLOC bit. This patch extends btrfs_ordered_update_i_size() to handle these cases. Signed-off-by: Yan Zheng --- diff -ur

[PATCH 5/8] Avoid orphan inodes cleanup during committing transaction

btrfs_lookup_dentry may trigger orphan cleanup, so it's not good to call it during committing transaction. Signed-off-by: Yan Zheng --- diff -urp 4/fs/btrfs/ioctl.c 5/fs/btrfs/ioctl.c --- 4/fs/btrfs/ioctl.c 2009-10-30 17:02:55.484797548 +0800 +++ 5/fs/btrfs/ioctl.c 2009-10-30 12:54:45.53704000

[PATCH 6/8] Avoid orphan inodes cleanup during replaying log

We do log replay in a single transaction, so it's not good to do unbound operations during replaying log. This patch makes orphan inodes cleanup executed after replaying log. It also avoid doing other unbound operations such as truncating a file during replaying log. These unbound operations are po

[PATCH 2/8] Add btrfs_duplicate_item

btrfs_duplicate_item duplicates item with new key, guaranteeing the source item and the new items are in the same tree leaf and contiguous. It allows us to split file extent in place, without using lock_extent to prevent bookend extent race. Signed-off-by: Yan Zheng --- diff -urp 1/fs/btrfs/ctre

[PATCH 3/8] Rewrite btrfs_drop_extents

Rewrite btrfs_drop_extents by using btrfs_duplicate_item, so we can avoid calling lock_extent within transaction. Signed-off-by: Yan Zheng --- diff -urp 2/fs/btrfs/ctree.h 3/fs/btrfs/ctree.h --- 2/fs/btrfs/ctree.h 2009-10-30 16:44:59.417790124 +0800 +++ 3/fs/btrfs/ctree.h 2009-10-30 16:50:52.9

[PATCH 1/8] Avoid superfluous tree-log writeout

We allow two log transactions at a time, but use same flag to mark dirty tree-log btree blocks. So we may flush dirty blocks belonging to newer log transaction when committing a log transaction. This patch fixes the issue by using two flags to mark dirty tree-log btree blocks. Signed-off-by: Yan Z