[PATCH v2] Btrfs: release subvolume's block_rsv before transaction commit

2014-01-08 Thread Liu Bo
We don't have to keep subvolume's block_rsv during transaction commit, and within transaction commit, we may also need the free space reclaimed from this block_rsv to process delayed refs. Signed-off-by: Liu Bo --- v2: rebase onto the latest btrfs-next. fs/btrfs/ioctl.c | 14 +++--- 1 f

Re: REQ: btrfs list option

2014-01-08 Thread Chris Murphy
On Jan 8, 2014, at 11:44 PM, Chris Murphy wrote: > > On Jan 8, 2014, at 11:27 PM, Chris Murphy wrote: > >> >> On Jan 8, 2014, at 9:06 PM, Alex wrote: >> >>> Chris Murphy colorremedies.com> writes: >>> Specify the mount point for the Btrfs file system and it will list all >>> subvols

Re: REQ: btrfs list option

2014-01-08 Thread Chris Murphy
On Jan 8, 2014, at 11:27 PM, Chris Murphy wrote: > > On Jan 8, 2014, at 9:06 PM, Alex wrote: > >> Chris Murphy colorremedies.com> writes: >> >>> Specify the mount point for the Btrfs file system and it will list all >> subvols on that file system. >>> >>> Chris Murphy-- >> >> Thank you Ch

Re: REQ: btrfs list option

2014-01-08 Thread Chris Murphy
On Jan 8, 2014, at 9:06 PM, Alex wrote: > Chris Murphy colorremedies.com> writes: > >> Specify the mount point for the Btrfs file system and it will list all > subvols on that file system. >> >> Chris Murphy-- > > Thank you Chris. > > When I do that on my version of the 3.12 userland: > # b

Re: REQ: btrfs list option

2014-01-08 Thread Alex
Chris Murphy colorremedies.com> writes: > Specify the mount point for the Btrfs file system and it will list all subvols on that file system. > > Chris Murphy-- Thank you Chris. When I do that on my version of the 3.12 userland: # btrfs sub list / -o returns nothing (with no error), which I w

Re: Problems with incremental send/receive

2014-01-08 Thread Wang Shilong
Hi Felix, It seems some reported this problem before. The problem for your below case is because you use latest btrfs-progs(v3.12?), which will need kernel update, kernel 3.12 is ok. However, i think btrfs-progs should keep compatibility, i will send a patch to make things more friendly. Th

[PATCH V2 1/2] Btrfs: fix the race between write back and nocow buffered write

2014-01-08 Thread Miao Xie
When we ran the 274th case of xfstests with nodatacow mount option, We met the following warning message: WARNING: CPU: 1 PID: 14185 at fs/btrfs/extent-tree.c:3734 btrfs_free_reserved_data_space+0xa6/0xd0 It is caused by the race between the write back and nocow buffered write: Task1

Re: REQ: btrfs list option

2014-01-08 Thread Chris Murphy
On Jan 8, 2014, at 6:31 PM, Alex wrote: > Hello > > (Using btrfs userland 3.12) > > I have my fs set up (below) I borrowed the Ubuntu scheme. > > /@/ > /@/etc > /@/var > .. > > get-default is 5 i.e. > > AFAICT, perhaps I'm missing the obvious, getting the list of subvolumes only > (no sna

Re: [PATCH v4 00/18] Replace btrfs_workers with kernel workqueue based btrfs_workqueue

2014-01-08 Thread Qu Wenruo
On Wed, 8 Jan 2014 19:51:59 +0100, David Sterba wrote: On Wed, Jan 08, 2014 at 02:25:02PM +0800, Qu Wenruo wrote: But according to the dmesg, which is expired now though, I made the following assumption: There is a possibility that out of order execution made the "work->wq = wq" sentence execut

REQ: btrfs list option

2014-01-08 Thread Alex
Hello (Using btrfs userland 3.12) I have my fs set up (below) I borrowed the Ubuntu scheme. /@/ /@/etc /@/var .. get-default is 5 i.e. AFAICT, perhaps I'm missing the obvious, getting the list of subvolumes only (no snapshots) is no longer trivial? # btrfs sub list /@ ERROR: can't access

Problems with incremental send/receive

2014-01-08 Thread Felix Blanke
Hi List, My backup stopped working and I can't figure out why. I'm using send/receive with the "-p" switch for incremental backups using the last snapshot as a parent snapshot for sending only the changed data. The problem occurs using my own backup script. After I discovered the problem I did a

[RFC PATCH] Btrfs-progs: Add optional 'uuid' parameter to mkfs.btrfs

2014-01-08 Thread Timothy Pepper
The patch below is a simple quick attempt at allowing the filesystem UUID to be specified by the user at mkfs time. Googling around I've seen a lot of people wishing they could "change their btrfs uuid". I understand why that's not going to happen. But this little patch seems like it could give t

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Kent Overstreet
On Wed, Jan 08, 2014 at 01:18:46PM -0800, Muthu Kumar wrote: > On Wed, Jan 8, 2014 at 1:14 PM, Kent Overstreet wrote: > > On Wed, Jan 08, 2014 at 09:11:49PM +, Chris Mason wrote: > >> On Wed, 2014-01-08 at 13:01 -0800, Muthu Kumar wrote: > >> > On Wed, Jan 8, 2014 at 12:51 PM, Chris Mason wro

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Jens Axboe
On 01/08/2014 02:13 PM, Chris Mason wrote: > On Tue, 2014-01-07 at 12:15 -0800, Muthu Kumar wrote: >> Thanks Fengguang. Final patch with added comment. BTW, fengguang >> mentioned that git-am has trouble with the inline patch and "quilt >> import" worked fine for him... >> >> >> In btr

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Muthu Kumar
On Wed, Jan 8, 2014 at 1:14 PM, Kent Overstreet wrote: > On Wed, Jan 08, 2014 at 09:11:49PM +, Chris Mason wrote: >> On Wed, 2014-01-08 at 13:01 -0800, Muthu Kumar wrote: >> > On Wed, Jan 8, 2014 at 12:51 PM, Chris Mason wrote: >> > > On Wed, 2014-01-08 at 12:40 -0800, Muthu Kumar wrote: >> >

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Chris Mason
On Tue, 2014-01-07 at 12:15 -0800, Muthu Kumar wrote: > Thanks Fengguang. Final patch with added comment. BTW, fengguang > mentioned that git-am has trouble with the inline patch and "quilt > import" worked fine for him... > > > In btrfs_end_bio(), we increment bi_remaining if is_orig

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Kent Overstreet
On Wed, Jan 08, 2014 at 09:11:49PM +, Chris Mason wrote: > On Wed, 2014-01-08 at 13:01 -0800, Muthu Kumar wrote: > > On Wed, Jan 8, 2014 at 12:51 PM, Chris Mason wrote: > > > On Wed, 2014-01-08 at 12:40 -0800, Muthu Kumar wrote: > > >> On Wed, Jan 8, 2014 at 12:16 PM, Chris Mason wrote: > > >

Re: btrfs on bcache

2014-01-08 Thread Kent Overstreet
On Wed, Jan 08, 2014 at 07:35:32PM +, Chris Mason wrote: > On Mon, 2014-01-06 at 15:37 -0800, Kent Overstreet wrote: > > Ok, I looked again at the relevant btrfs code, I guess I can see how this > > printk > > isn't normally triggered. But Chris, _what on earth_ is btrfs trying to > > check >

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Chris Mason
On Wed, 2014-01-08 at 13:01 -0800, Muthu Kumar wrote: > On Wed, Jan 8, 2014 at 12:51 PM, Chris Mason wrote: > > On Wed, 2014-01-08 at 12:40 -0800, Muthu Kumar wrote: > >> On Wed, Jan 8, 2014 at 12:16 PM, Chris Mason wrote: > >> > On Wed, 2014-01-08 at 11:54 -0800, Muthu Kumar wrote: > >> >> Chris

I have a very lucrative Business

2014-01-08 Thread Dr. Musa Hamed
ATTN: Dear, I am Dr. Musa Hamed Executive Director of the Bank of Africa Plc B.O.A,Cotonou Benin Rep. I have a very lucrative Business proposal worth of 21,500,000.00 USD. An Iraqi named Hamadi Hashem a business man made a fixed deposit of 21,500,000.00 USD . Upon maturity several notices was sen

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Muthu Kumar
On Wed, Jan 8, 2014 at 12:51 PM, Chris Mason wrote: > On Wed, 2014-01-08 at 12:40 -0800, Muthu Kumar wrote: >> On Wed, Jan 8, 2014 at 12:16 PM, Chris Mason wrote: >> > On Wed, 2014-01-08 at 11:54 -0800, Muthu Kumar wrote: >> >> Chris, >> >> >> >> [8.336061] WARNING: CPU: 0 PID: 0 at fs/bio.c:

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Chris Mason
On Wed, 2014-01-08 at 12:40 -0800, Muthu Kumar wrote: > On Wed, Jan 8, 2014 at 12:16 PM, Chris Mason wrote: > > On Wed, 2014-01-08 at 11:54 -0800, Muthu Kumar wrote: > >> Chris, > >> > >> [8.336061] WARNING: CPU: 0 PID: 0 at fs/bio.c:1778 > >> bio_endio+0xbe/0x100() > >> [8.336062] bio_en

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Muthu Kumar
On Wed, Jan 8, 2014 at 12:16 PM, Chris Mason wrote: > On Wed, 2014-01-08 at 11:54 -0800, Muthu Kumar wrote: >> Chris, >> >> [8.336061] WARNING: CPU: 0 PID: 0 at fs/bio.c:1778 bio_endio+0xbe/0x100() >> [8.336062] bio_endio: bio for (unknown) without endio >> >> This is my recent change to a

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Chris Mason
On Wed, 2014-01-08 at 11:54 -0800, Muthu Kumar wrote: > Chris, > > [8.336061] WARNING: CPU: 0 PID: 0 at fs/bio.c:1778 bio_endio+0xbe/0x100() > [8.336062] bio_endio: bio for (unknown) without endio > > This is my recent change to avoid memory leak in bio_endio. But I > think the problem is

Re: [PATCH 0/7] Patches to support subpagesize blocksize

2014-01-08 Thread Chandra Seetharaman
Hello All, I had some random corruption issues when I run some serious IOs with these patches. Found out that the function clean_tree_block() is the problem. IIUC, this function is used to drop a dirty extent buffer when it is not needed any more to be written to the disk. In my case, the exten

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Muthu Kumar
Chris, [8.336061] WARNING: CPU: 0 PID: 0 at fs/bio.c:1778 bio_endio+0xbe/0x100() [8.336062] bio_endio: bio for (unknown) without endio This is my recent change to avoid memory leak in bio_endio. But I think the problem is higher up, most likely bio_endio is called twice on the same bio (w

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

2014-01-08 Thread Chris Mason
On Tue, 2014-01-07 at 13:23 -0800, Muthu Kumar wrote: > Chris, > This is based off of Jens block tree, for-3.14/core branch... > Ok, Kent did pull in one of my hunks, one was a comment and the third was effectively the same as your patch. I tried to test the end result today, but get these on bo

Re: btrfs on bcache

2014-01-08 Thread Chris Mason
On Mon, 2014-01-06 at 15:37 -0800, Kent Overstreet wrote: > On Fri, Dec 20, 2013 at 03:46:30PM +, Chris Mason wrote: > > On Fri, 2013-12-20 at 10:42 -0200, Fábio Pfeifer wrote: > > > Hello, > > > > > > I put the "WARN_ON(1);" after the printk lines (incomplete page read > > > and incomplete pa

Re: [PATCH v4 00/18] Replace btrfs_workers with kernel workqueue based btrfs_workqueue

2014-01-08 Thread David Sterba
On Wed, Jan 08, 2014 at 02:25:02PM +0800, Qu Wenruo wrote: > >But according to the dmesg, which is expired now though, I made the > >following assumption: > > > >There is a possibility that out of order execution made the "work->wq = > >wq" sentence executed behind the "queue_work()" call, > >and t

Re: [PATCH 2/2] Btrfs: release subvolume's block_rsv before transaction commit

2014-01-08 Thread Josef Bacik
On 12/29/2013 08:44 AM, Liu Bo wrote: We don't have to keep subvolume's block_rsv during transaction commit, and within transaction commit, we may also need the free space reclaimed from this block_rsv to process delayed refs. Signed-off-by: Liu Bo --- fs/btrfs/ioctl.c | 7 --- 1 file c

Re: [PATCH] btrfs: Return EXDEV for cross file system snapshot

2014-01-08 Thread David Sterba
On Wed, Jan 08, 2014 at 07:46:19PM +0900, Kusanagi Kouichi wrote: > EXDEV seems an appropriate error if an operation fails bacause it > crosses file system boundaries. > > Signed-off-by: Kusanagi Kouichi Reviewed-by: David Sterba -- To unsubscribe from this list: send the line "unsubscribe linux

Re: [PATCH v2 1/4] Btrfs: fix wrong send_in_progress accounting

2014-01-08 Thread Wang Shilong
Hello David, > On Tue, Jan 07, 2014 at 05:25:18PM +0800, Wang Shilong wrote: >> Steps to reproduce: >> # mkfs.btrfs -f /dev/sda8 >> # mount /dev/sda8 /mnt >> # btrfs sub snapshot -r /mnt /mnt/snap1 >> # btrfs sub snapshot -r /mnt /mnt/snap2 >> # btrfs send /mnt/snap1 -p /mnt/snap2 -f /mnt/1 >> #

Re: [PATCH 1/2] Btrfs: fix the race between write back and nocow buffered write

2014-01-08 Thread Josef Bacik
On 12/27/2013 08:11 AM, Miao Xie wrote: When we ran the 274th case of xfstests with nodatacow mount option, We met the following warning message: WARNING: CPU: 1 PID: 14185 at fs/btrfs/extent-tree.c:3734 btrfs_free_reserved_data_space+0xa6/0xd0 It is caused by the race between the write back a

Re: [PATCH 2/3] Btrfs: rework qgroup accounting

2014-01-08 Thread David Sterba
On Wed, Dec 18, 2013 at 04:07:28PM -0500, Josef Bacik wrote: > /* > - * btrfs_qgroup_record_ref is called when the ref is added or deleted. it > puts > - * the modification into a list that's later used by btrfs_end_transaction to > - * pass the recorded modifications on to btrfs_qgroup_account_r

Re: [PATCH 2/3] Btrfs: rework qgroup accounting

2014-01-08 Thread Josef Bacik
On 01/08/2014 09:33 AM, David Sterba wrote: On Wed, Dec 18, 2013 at 04:07:28PM -0500, Josef Bacik wrote: /* - * btrfs_qgroup_record_ref is called when the ref is added or deleted. it puts - * the modification into a list that's later used by btrfs_end_transaction to - * pass the recorded modi

Re: [PATCH v2 1/4] Btrfs: fix wrong send_in_progress accounting

2014-01-08 Thread David Sterba
On Tue, Jan 07, 2014 at 05:25:18PM +0800, Wang Shilong wrote: > Steps to reproduce: > # mkfs.btrfs -f /dev/sda8 > # mount /dev/sda8 /mnt > # btrfs sub snapshot -r /mnt /mnt/snap1 > # btrfs sub snapshot -r /mnt /mnt/snap2 > # btrfs send /mnt/snap1 -p /mnt/snap2 -f /mnt/1 > # dmesg > > The pro

[PATCH] btrfs: Return EXDEV for cross file system snapshot

2014-01-08 Thread Kusanagi Kouichi
EXDEV seems an appropriate error if an operation fails bacause it crosses file system boundaries. Signed-off-by: Kusanagi Kouichi --- fs/btrfs/ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 21da576..15d35cb 100644 --- a/fs/bt

Re: btrfs-transaction blocked for more than 120 seconds

2014-01-08 Thread Duncan
Marc MERLIN posted on Tue, 07 Jan 2014 19:22:58 -0800 as excerpted: > On Fri, Jan 03, 2014 at 09:34:10PM +, Duncan wrote: >> IIRC someone also mentioned problems with autodefrag and an about 3/4 >> gig systemd journal. My gut feeling (IOW, *NOT* benchmarked!) is that >> double-digit MiB files

Re: Is anyone using btrfs send/receive howto?

2014-01-08 Thread Marc MERLIN
On Tue, Jan 07, 2014 at 10:53:29AM +, Hugo Mills wrote: >You need to move /mnt/btrfs_pool2/tmp_read_only_new to a different > name as well. The send stream contains the name of the subvolume it > wants to create, so it's trying to create a subvolume called > "tmp_read_only_new" in /mnt/btrf