Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

On Fri, Feb 22, 2013 at 2:40 PM, Josef Bacik wrote: > On Fri, Feb 22, 2013 at 11:31:07AM -0700, Mace Moneta wrote: >> On Fri, Feb 22, 2013 at 1:16 PM, Mace Moneta wrote: >> > On Fri, Feb 22, 2013 at 1:10 PM, Josef Bacik wrote: >> >> On Fri, Feb 22, 2013 at 10:52:19AM -0700, Mace Moneta wrote: >>

Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

Hello, David 2013/2/23 David Sterba : > On Sat, Feb 23, 2013 at 12:39:24AM +0800, Shilong Wang wrote: >> Hello, >> >> 2013/2/22 Arne Jansen : >> > On 02/22/13 13:09, Wang Shilong wrote: >> >> From: Wang Shilong >> >> >> >> This patch tries to stop users to create/destroy qgroup level 0, >> >> use

Re: [Tests] xfs test[298]: Btrfs Quota testing

On Fri, Feb 22, 2013 at 11:24:04AM +0530, Hemanth Kumar wrote: > > Signed-off-by: Hemanth Kumar Description? > --- > 298 | 37 + > 298.out | 12 > 2 files changed, 49 insertions(+) > create mode 100644 298 > create mode 100644 298.out You

Changing allocation mode

Dear list, I'm still in the process of transferring all the data I have to the btrfs filesystem I have had your help in debugging in a previous thread, and I have a slight question, if you will humour me. I have the data I want to transfer on an old ReiserFS partition, consisting of 2 mdraid

Re: Rebalancing RAID1

On Mon, 18 Feb 2013, Stefan Behrens wrote: On Fri, 15 Feb 2013 22:56:19 +0100 (CET), Fredrik Tolf wrote: The oops cut can be found here: This scrub issue is fixed since Linux 3.8-rc1 with commit 4ded4f6 Btrfs: fix BUG() in scrub when first sup

Re: [RFC][PATCH] btrfs: clean snapshots one by one

On Sun, Feb 17, 2013 at 09:55:23PM +0200, Alex Lyakas wrote: > > --- a/fs/btrfs/disk-io.c > > +++ b/fs/btrfs/disk-io.c > > @@ -1635,15 +1635,17 @@ static int cleaner_kthread(void *arg) > > struct btrfs_root *root = arg; > > > > do { > > + int again = 0; > > + > >

Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

On Sat, Feb 23, 2013 at 12:39:24AM +0800, Shilong Wang wrote: > Hello, > > 2013/2/22 Arne Jansen : > > On 02/22/13 13:09, Wang Shilong wrote: > >> From: Wang Shilong > >> > >> This patch tries to stop users to create/destroy qgroup level 0, > >> users can only create/destroy qgroup level more tha

Re: [bug] mkfs.btrfs reports device busy for ext4 mounted disk

On Fri, Feb 22, 2013 at 11:03:25AM -0800, Zach Brown wrote: > > Next, since previously we had btrfs on sdb and mkfs.ext4 > > does not overwrite super-block mirror 1.. so > > > >btrfs_read_dev_super(int fd, struct btrfs_super_block *sb, u64 > > sb_bytenr) > > > > finds btrfs on sdb. > > bt

Re: [PATCH] Btrfs: update inode flags when renaming

On Fri, Feb 22, 2013 at 04:19:27PM -0500, Marios Titas wrote: > I think that many end users will find all this very confusing. They > will never expect that renaming a file will cause it to suddenly lose > one flag (NODATACOW) while preserving the other (NODATASUM). > Especially since they cannot e

Re: [PATCH] Btrfs: update inode flags when renaming

On Fri, Feb 22, 2013 at 05:34:47PM +0800, Miao Xie wrote: > Onfri, 22 Feb 2013 16:40:35 +0800, Liu Bo wrote: > > On Fri, Feb 22, 2013 at 03:32:50AM -0500, Marios Titas wrote: > >> Sorry, but the bug persists even with the above patch. > >> > >> touch test > >> chattr +C test > >> lsattr test >

Re: [PATCH] Btrfs: update inode flags when renaming

On Fri, Feb 22, 2013 at 5:00 AM, Liu Bo wrote: > On Fri, Feb 22, 2013 at 04:10:37AM -0500, Marios Titas wrote: >> You are right, your patch does improve the situation a bit. But it >> still does not address the main issue. To illustrate that, consider >> the following scenario: > > Sorry for so mu

Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

On Fri, Feb 22, 2013 at 11:31:07AM -0700, Mace Moneta wrote: > On Fri, Feb 22, 2013 at 1:16 PM, Mace Moneta wrote: > > On Fri, Feb 22, 2013 at 1:10 PM, Josef Bacik wrote: > >> On Fri, Feb 22, 2013 at 10:52:19AM -0700, Mace Moneta wrote: > >>> On Fri, Feb 22, 2013 at 12:44 PM, Josef Bacik wrote:

Re: [bug] mkfs.btrfs reports device busy for ext4 mounted disk

> Next, since previously we had btrfs on sdb and mkfs.ext4 > does not overwrite super-block mirror 1.. so > >btrfs_read_dev_super(int fd, struct btrfs_super_block *sb, u64 > sb_bytenr) > > finds btrfs on sdb. btrfs-progs shouldn't be unconditionally trusting the backup superblocks if the

Re: copy on write misconception

On Fri, Feb 22, 2013 at 11:41 AM, Mike Power wrote: > On 02/22/2013 09:16 AM, Hugo Mills wrote: >> >> On Fri, Feb 22, 2013 at 09:11:28AM -0800, Mike Power wrote: >>> >>> I think I have a misconception of what copy on write in btrfs means >>> for individual files. >>> >>> I had originally thought t

Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

On Fri, Feb 22, 2013 at 1:16 PM, Mace Moneta wrote: > On Fri, Feb 22, 2013 at 1:10 PM, Josef Bacik wrote: >> On Fri, Feb 22, 2013 at 10:52:19AM -0700, Mace Moneta wrote: >>> On Fri, Feb 22, 2013 at 12:44 PM, Josef Bacik wrote: >>> > On Fri, Feb 22, 2013 at 10:22:04AM -0700, Mace Moneta wrote: >>

Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

On Fri, Feb 22, 2013 at 1:10 PM, Josef Bacik wrote: > On Fri, Feb 22, 2013 at 10:52:19AM -0700, Mace Moneta wrote: >> On Fri, Feb 22, 2013 at 12:44 PM, Josef Bacik wrote: >> > On Fri, Feb 22, 2013 at 10:22:04AM -0700, Mace Moneta wrote: >> >> On Fri, Feb 22, 2013 at 11:53 AM, Josef Bacik wrote:

Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

On Fri, Feb 22, 2013 at 10:52:19AM -0700, Mace Moneta wrote: > On Fri, Feb 22, 2013 at 12:44 PM, Josef Bacik wrote: > > On Fri, Feb 22, 2013 at 10:22:04AM -0700, Mace Moneta wrote: > >> On Fri, Feb 22, 2013 at 11:53 AM, Josef Bacik wrote: > >> > On Fri, Feb 22, 2013 at 07:46:16AM -0700, Mace Mone

Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

On Fri, Feb 22, 2013 at 12:44 PM, Josef Bacik wrote: > On Fri, Feb 22, 2013 at 10:22:04AM -0700, Mace Moneta wrote: >> On Fri, Feb 22, 2013 at 11:53 AM, Josef Bacik wrote: >> > On Fri, Feb 22, 2013 at 07:46:16AM -0700, Mace Moneta wrote: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=906142 >>

Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

On Fri, Feb 22, 2013 at 10:22:04AM -0700, Mace Moneta wrote: > On Fri, Feb 22, 2013 at 11:53 AM, Josef Bacik wrote: > > On Fri, Feb 22, 2013 at 07:46:16AM -0700, Mace Moneta wrote: > >> https://bugzilla.redhat.com/show_bug.cgi?id=906142 > >> > >> With 3.8 kernels in Fedora 18, using encfs on btrfs

Re: copy on write misconception

On 02/22/2013 09:16 AM, Hugo Mills wrote: On Fri, Feb 22, 2013 at 09:11:28AM -0800, Mike Power wrote: I think I have a misconception of what copy on write in btrfs means for individual files. I had originally thought that I could create a large file: time dd if=/dev/zero of=10G bs=1G count=10 1

Re: copy on write misconception

> Then if I copied this file no blocks would be copied until they are written. > Hence the two files would use the same blocks underneath. But specifically > that copy would be fast. Since it would only need to write some metadata. > But when I copy the file: > time cp 10G 10G2 cp without argumen

Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

On Fri, Feb 22, 2013 at 11:53 AM, Josef Bacik wrote: > On Fri, Feb 22, 2013 at 07:46:16AM -0700, Mace Moneta wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=906142 >> >> With 3.8 kernels in Fedora 18, using encfs on btrfs I get the >> following error. It can take hours of use before I get a

Re: copy on write misconception

On Fri, Feb 22, 2013 at 09:11:28AM -0800, Mike Power wrote: > I think I have a misconception of what copy on write in btrfs means > for individual files. > > I had originally thought that I could create a large file: > time dd if=/dev/zero of=10G bs=1G count=10 > 10+0 records in > 10+0 records out

copy on write misconception

I think I have a misconception of what copy on write in btrfs means for individual files. I had originally thought that I could create a large file: time dd if=/dev/zero of=10G bs=1G count=10 10+0 records in 10+0 records out 10737418240 bytes (11 GB) copied, 100.071 s, 107 MB/s real1m41.082

Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

On Fri, Feb 22, 2013 at 07:46:16AM -0700, Mace Moneta wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=906142 > > With 3.8 kernels in Fedora 18, using encfs on btrfs I get the > following error. It can take hours of use before I get a > reoccurrence, and I need to btrfsck, btrfs-zero-log, and

Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

Hello, 2013/2/22 Arne Jansen : > On 02/22/13 13:09, Wang Shilong wrote: >> From: Wang Shilong >> >> This patch tries to stop users to create/destroy qgroup level 0, >> users can only create/destroy qgroup level more than 0. >> >> See the fact: >> a subvolume/snapshot qgroup was created auto

Re: [PATCH 1/2] Btrfs: create the qgroup that limits root subvolume automatically

2013/2/22 Arne Jansen : > On 02/22/13 13:02, Wang Shilong wrote: >> From: Wang Shilong >> >> Creating the root subvolume qgroup when enabling quota,with > > Why only create a qgroup for the root subvolume and not for > every existing subvolume? > Yes，You are right. Creating all the existed subvol

Re: clear chunk_alloc flag on retryable failure

On Thu, Feb 21, 2013 at 02:15:14PM -0700, Alexandre Oliva wrote: > I've experienced filesystem freezes with permanent spikes in the active > process count for quite a while, particularly on filesystems whose > available raw space has already been fully allocated to chunks. > > While looking into t

Re: collapse concurrent forced allocations (was: Re: clear chunk_alloc flag on retryable failure)

On Thu, Feb 21, 2013 at 06:15:49PM -0700, Alexandre Oliva wrote: > On Feb 21, 2013, Alexandre Oliva wrote: > > > What I saw in that function also happens to explain why in some cases I > > see filesystems allocate a huge number of chunks that remain unused > > (leading to the scenario above, of n

WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

https://bugzilla.redhat.com/show_bug.cgi?id=906142 With 3.8 kernels in Fedora 18, using encfs on btrfs I get the following error. It can take hours of use before I get a reoccurrence, and I need to btrfsck, btrfs-zero-log, and/or mount with '-o recovery' to get the filesystem back after a reboot.

Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

On 02/22/13 13:09, Wang Shilong wrote: > From: Wang Shilong > > This patch tries to stop users to create/destroy qgroup level 0, > users can only create/destroy qgroup level more than 0. > > See the fact: > a subvolume/snapshot qgroup was created automatically > when creating subvolume/sna

Re: [PATCH 1/2] Btrfs: create the qgroup that limits root subvolume automatically

On 02/22/13 13:02, Wang Shilong wrote: > From: Wang Shilong > > Creating the root subvolume qgroup when enabling quota,with Why only create a qgroup for the root subvolume and not for every existing subvolume? > this patch,it will be ok to limit the whole filesystem size. This will not limit t

[RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

From: Wang Shilong This patch tries to stop users to create/destroy qgroup level 0, users can only create/destroy qgroup level more than 0. See the fact: a subvolume/snapshot qgroup was created automatically when creating subvolume/snapshot, so creating a qgroup level 0 can't be a subvol

[PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

From: Wang Shilong This patch tries to stop users to create/destroy qgroup level 0, users can only create/destroy qgroup level more than 0. See the fact: a subvolume/snapshot qgroup was created automatically when creating subvolume/snapshot, so creating a qgroup level 0 can't be a subvol

[PATCH 1/2] Btrfs: create the qgroup that limits root subvolume automatically

From: Wang Shilong Creating the root subvolume qgroup when enabling quota,with this patch,it will be ok to limit the whole filesystem size. Signed-off-by: Wang Shilong Reviewed-by: Miao Xie Cc: Arne Jansen --- fs/btrfs/qgroup.c | 12 1 files changed, 12 insertions(+), 0 deleti

Re: Snapshot Cleaner not Working with inode_cache

On Fri, Feb 22, 2013 at 11:16:22AM +0100, Norbert Scheibner wrote: > Am 20.02.2013, 02:14 Uhr, schrieb Liu Bo : > > >I think I know why inode_cache keeps us from freeing space, > >inode_cache adds > >a cache_inode in each btrfs root, and this cache_inode will be > >iput at the very > >last of stag

Re: Snapshot Cleaner not Working with inode_cache

Am 20.02.2013, 02:14 Uhr, schrieb Liu Bo : I think I know why inode_cache keeps us from freeing space, inode_cache adds a cache_inode in each btrfs root, and this cache_inode will be iput at the very last of stage during umount, ie. after we do cleanup work on old snapshot/subvols, where we

Re: [PATCH] Btrfs: update inode flags when renaming

On Fri, Feb 22, 2013 at 05:34:47PM +0800, Miao Xie wrote: > Onfri, 22 Feb 2013 16:40:35 +0800, Liu Bo wrote: > > On Fri, Feb 22, 2013 at 03:32:50AM -0500, Marios Titas wrote: > >> Sorry, but the bug persists even with the above patch. > >> > >> touch test > >> chattr +C test > >> lsattr test >

Re: [PATCH] Btrfs: update inode flags when renaming

On Fri, Feb 22, 2013 at 04:10:37AM -0500, Marios Titas wrote: > You are right, your patch does improve the situation a bit. But it > still does not address the main issue. To illustrate that, consider > the following scenario: Sorry for so much confusion for users. Please let me explain the follo

Re: [PATCH] Btrfs: update inode flags when renaming

Wouldn't though inheriting create all sorts of problems? For instance check the example that I give in my other responese [1]. [1] http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg22396.html On Fri, Feb 22, 2013 at 4:34 AM, Miao Xie wrote: > On fri, 22 Feb 2013 16:40:35 +0800, Liu

Re: [PATCH] Btrfs: update inode flags when renaming

On fri, 22 Feb 2013 16:40:35 +0800, Liu Bo wrote: > On Fri, Feb 22, 2013 at 03:32:50AM -0500, Marios Titas wrote: >> Sorry, but the bug persists even with the above patch. >> >> touch test >> chattr +C test >> lsattr test >> mv test test2 >> lsattr test2 >> >> In the above scenario test2 will

Re: [PATCH] Btrfs: update inode flags when renaming

You are right, your patch does improve the situation a bit. But it still does not address the main issue. To illustrate that, consider the following scenario: touch test chattr +C test head -c 1048576 /dev/zero >> test mv test test2 now test2 lost the C flag because it was renamed. But the data i

Re: [PATCH] Btrfs: update inode flags when renaming

On Fri, Feb 22, 2013 at 03:32:50AM -0500, Marios Titas wrote: > Sorry, but the bug persists even with the above patch. > > touch test > chattr +C test > lsattr test > mv test test2 > lsattr test2 > > In the above scenario test2 will not have the C flag. What do you expect? IMO it's right that t

Re: [PATCH] Btrfs: use reserved space for creating a snapshot

On fri, 22 Feb 2013 12:33:36 +0800, Liu Bo wrote: > While inserting dir index and updating inode for a snapshot, we'd > add delayed items which consume trans->block_rsv, if we don't have > any space reserved in this trans handle, we either just return or > reserve space again. > > But before creat

Re: [PATCH] Btrfs: update inode flags when renaming

Sorry, but the bug persists even with the above patch. touch test chattr +C test lsattr test mv test test2 lsattr test2 In the above scenario test2 will not have the C flag. On Fri, Feb 22, 2013 at 3:11 AM, Liu Bo wrote: > A user reported some weird behaviours, > if we move a file with the noCo

Re: [PATCH v2] btrfs: use kmalloc for lzo de/compress buffer

On Thu, Feb 21, 2013 at 02:41:53PM +0100, David Sterba wrote: > On Mon, Feb 18, 2013 at 04:56:04PM +0900, Kyungsik Lee wrote: > > @@ -55,8 +55,9 @@ static struct list_head *lzo_alloc_workspace(void) > > return ERR_PTR(-ENOMEM); > > > > workspace->mem = vmalloc(LZO1X_MEM_COMPRESS);

[PATCH] Btrfs: update inode flags when renaming

A user reported some weird behaviours, if we move a file with the noCow flag to a directory without the noCow flag, the file is now without the flag, but after remount, we'll find the file's noCow flag comes back. This is because we missed a proper inode update after inheriting parent directory's