[PATCH][RFC] Btrfs: Treat -EDQUOT like -ENOSPC during unlink

2015-06-03 Thread jmaggard10
From: Justin Maggard jmaggar...@gmail.com Error messages saying, basically, you don't have enough free space to free up space make people angry. Sure, there are workarounds like truncating a file before removing it; but it's certainly not obvious. Unlink has a special case if we cannot make our

Re: [PATCH] Btrfs: btrfs_defrag_file: Fix calculation of max_to_defrag.

2015-06-03 Thread David Sterba
On Wed, Jun 03, 2015 at 02:59:54PM +0530, Chandan Rajendra wrote: max_to_defrag represents the number of pages to defrag rather than the last page of the file range to be defragged. Fix this. Please update the changelog and describe the buggy behaviour. From a brief look I think that the defrag

Re: [PATCH] Btrfs: don't invalidate root dentry when subvolume deletion fails

2015-06-03 Thread David Sterba
On Tue, Jun 02, 2015 at 05:19:14PM -0700, Omar Sandoval wrote: I also can't figure out what that shrink_dcache_sb() is doing there. d_invalidate() already prunes the dentry cache under the deleted subvolume, but this clears the dcache for the whole filesystem, which could incur unnecessary

Re: [PATCH] btrfs: qgroup: allow user to clear the limitation on qgroup

2015-06-03 Thread Tsutomu Itoh
On 2015/06/03 15:57, Dongsheng Yang wrote: Currently, we can only set a limitation on a qgroup, but we can not clear it. This patch provide a choice to user to clear a limitation on qgroup by passing a value of CLEAR_VALUE(-1) to kernel. Reported-by: Tsutomu Itoh t-i...@jp.fujitsu.com

Re: [PATCH 2/2] btrfs-progs: qgroup: allow user to clear some limitation on qgroup.

2015-06-03 Thread Tsutomu Itoh
On 2015/06/03 15:57, Dongsheng Yang wrote: Currently, we can not clear a limitation on a qgroup. Although there is a 'none' choice provided to user to do it, it does not work well. It does not set the flag which user want to clear, then kernel will never know what the user want to do at

[PATCH 2/2] btrfs-progs: qgroup limit: add a check for invalid input of 'T/G/M/K'

2015-06-03 Thread Dongsheng Yang
Add a check to error out in the following case: # ./btrfs qgroup limit T /mnt/ Invalid size argument given Without this patch, btrfs-progs would parse the input as 0 and continue. Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com --- cmds-qgroup.c | 3 +++ 1 file changed, 3

[PATCH 1/2] btrfs-progs: qgroup: show 'none' when we did not limit it on this qgroup

2015-06-03 Thread Dongsheng Yang
There are two understanding of the '0' value in btrfs qgroup show. (1) is no-limitation on this qgroup. (2) is the max-limitation is 0. This patch make it showing in different way. (1). max-limitation for 0 is still showing '0'. (2). no-limitation will show 'none'. qgroupid rfer

[PATCH 2/2] btrfs-progs: qgroup: allow user to clear some limitation on qgroup.

2015-06-03 Thread Dongsheng Yang
Currently, we can not clear a limitation on a qgroup. Although there is a 'none' choice provided to user to do it, it does not work well. It does not set the flag which user want to clear, then kernel will never know what the user want to do at all. *Without this commit* # ./btrfs qgroup show

[PATCH] btrfs: qgroup: allow user to clear the limitation on qgroup

2015-06-03 Thread Dongsheng Yang
Currently, we can only set a limitation on a qgroup, but we can not clear it. This patch provide a choice to user to clear a limitation on qgroup by passing a value of CLEAR_VALUE(-1) to kernel. Reported-by: Tsutomu Itoh t-i...@jp.fujitsu.com Signed-off-by: Dongsheng Yang

Re: [PATCH 1/2] btrfs-progs: avoid duplicate checks on user provided devid

2015-06-03 Thread Anand Jain
On 06/02/2015 11:12 PM, David Sterba wrote: On Mon, Jun 01, 2015 at 02:25:17PM +0800, Anand Jain wrote: kernel is already checking it (rightly), we don't need to check that in the user land. Sometimes it's useful to duplicate the checks in userspace because we can fail early and return the

[PATCH 1/2] btrfs-progs: qgroup limit: error out if input value is negative

2015-06-03 Thread Dongsheng Yang
If we pass a negative value to command qgroup limit, btrfs-progs would convert it to unsigned long long silently. That's a little confusing to user, why I can limit my quota to a negative value. This patch add a check in parse_limit, if the input value is negative, error out to user.

[PATCH] xfstests: btrfs: 022: add a quota rescan -w to wait rescan finished.

2015-06-03 Thread Dongsheng Yang
When we enable quota, btrfs will rescan quota numbers. We need to wait the rescan finished before any more operations on btrfs qgroups. Otherwith, the new btrfs-progs would WARN out: WARNING: Rescan is running, qgroup data may be incorrect. It would make btrfs/022 failed. Signed-off-by:

Re: [PATCH 1/2] btrfs-progs: qgroup: show 'none' when we did not limit it on this qgroup

2015-06-03 Thread Tsutomu Itoh
On 2015/06/03 15:57, Dongsheng Yang wrote: There are two understanding of the '0' value in btrfs qgroup show. (1) is no-limitation on this qgroup. (2) is the max-limitation is 0. This patch make it showing in different way. (1). max-limitation for 0 is still showing '0'. (2).

Re: [PATCH] xfstests: btrfs: 022: add a quota rescan -w to wait rescan finished.

2015-06-03 Thread Dongsheng Yang
Hi Filip, Qu is off duty this week, would you please try this patch here? Thanx Yang On 06/03/2015 03:10 PM, Dongsheng Yang wrote: When we enable quota, btrfs will rescan quota numbers. We need to wait the rescan finished before any more operations on btrfs qgroups. Otherwith, the new

Re: [PATCH 2/2] btrfs-progs: qgroup: allow user to clear some limitation on qgroup.

2015-06-03 Thread Dongsheng Yang
On 06/03/2015 04:40 PM, Tsutomu Itoh wrote: On 2015/06/03 15:57, Dongsheng Yang wrote: Currently, we can not clear a limitation on a qgroup. Although there is a 'none' choice provided to user to do it, it does not work well. It does not set the flag which user want to clear, then kernel

[PATCH] Btrfs: btrfs_defrag_file: Fix calculation of max_to_defrag.

2015-06-03 Thread Chandan Rajendra
max_to_defrag represents the number of pages to defrag rather than the last page of the file range to be defragged. Fix this. Signed-off-by: Chandan Rajendra chan...@linux.vnet.ibm.com --- fs/btrfs/ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ioctl.c

[PATCH] btrfs: cleanup, stop casting for extent_map-lookup everywhere

2015-06-03 Thread jeffm
From: Jeff Mahoney je...@suse.com Overloading extent_map-bdev to struct map_lookup * might have started out as a means to an end, but it's a pattern that's used all over the place now. Let's get rid of the casting and just add a union instead. Signed-off-by: Jeff Mahoney je...@suse.com ---

[PATCH 3/3] btrfs: add missing discards when unpinning extents with -o discard

2015-06-03 Thread jeffm
From: Jeff Mahoney je...@suse.com When we clear the dirty bits in btrfs_delete_unused_bgs for extents in the empty block group, it results in btrfs_finish_extent_commit being unable to discard the freed extents. The block group removal patch added an alternate path to forget extents other than

[PATCH v3] btrfs: fix automatic blockgroup remove + discard

2015-06-03 Thread jeffm
The automatic block group removal patch introduced some regressions in how discards are handled. 1/ FITRIM only iterates over block groups on disk - removed block groups won't be trimmed. 2/ Clearing the dirty bit from extents in removed block groups means that those extents won't be

[PATCH 2/3] btrfs: explictly delete unused block groups in close_ctree and ro-remount

2015-06-03 Thread jeffm
From: Jeff Mahoney je...@suse.com The cleaner thread may already be sleeping by the time we enter close_ctree. If that's the case, we'll skip removing any unused block groups queued for removal, even during a normal umount. They'll be cleaned up automatically at next mount, but users expect a

[RFC] add a bi_error field

2015-06-03 Thread Christoph Hellwig
Bio error reporting has been a mess for a while, and the increasing use of chained bios makes it worse. This series attempts to add a proper error field to struct bio to sort this out. It's working fine for me, but MD and btrfs were doing pretty nasty things with the BIO_UPTODATE flag, so I

Re: [PATCH] Btrfs: btrfs_defrag_file: Fix calculation of max_to_defrag.

2015-06-03 Thread Chandan Rajendra
On Wednesday 03 Jun 2015 12:41:02 David Sterba wrote: On Wed, Jun 03, 2015 at 02:59:54PM +0530, Chandan Rajendra wrote: max_to_defrag represents the number of pages to defrag rather than the last page of the file range to be defragged. Fix this. Please update the changelog and describe

btrfs refuses to mount rw, access yields ESTALE on ro mount

2015-06-03 Thread fuz
Hello! I'm experiencing a problem with a btrfs partition on my system. It refuses to mount rw, dmesg contains this message and a stack trace [0] when I try: BTRFS info (device sdb1): disk space caching is enabled I can mount the fs as readonly but then I get a bunch of these errors on file

Re: [PATCH] xfstests: btrfs: 022: add a quota rescan -w to wait rescan finished.

2015-06-03 Thread Filipe David Manana
On Wed, Jun 3, 2015 at 8:10 AM, Dongsheng Yang yangds.f...@cn.fujitsu.com wrote: When we enable quota, btrfs will rescan quota numbers. We need to wait the rescan finished before any more operations on btrfs qgroups. Otherwith, the new btrfs-progs would WARN out: WARNING: Rescan is running,

[PATCH 2/2 RESEND] Btrfs: incremental send, check if orphanized dir inode needs delayed rename

2015-06-03 Thread Filipe Manana
If a directory inode is orphanized, because some inode previously processed has a new name that collides with the old name of the current inode, we need to check if it needs its rename operation delayed too, as its ancestor-descendent relationship with some other inode might have been reversed

[GIT PULL] Send fixes for 4.2

2015-06-03 Thread Filipe Manana
Hi Chris, Please pull 2 fixes for the send feature from my branch send_fixes_4.2. Both have been around in the mailing list/patchwork before the 4.1 merge window opened but were not picked for 4.1. They both have tests merged in xfstests (btrfs/087 and btrfs/092), which as expected, fail without

[PATCH 1/2 RESEND] Btrfs: incremental send, don't delay directory renames unnecessarily

2015-06-03 Thread Filipe Manana
Even though we delay the rename of directories when they become descendents of other directories that were also renamed in the send root to prevent infinite path build loops, we were doing it in cases where this was not needed and was actually harmful resulting in infinite path build loops as we

(no subject)

2015-06-03 Thread Irena A.
Hello My name is Irena .A, I am sending this brief letter to solicit your partnership to transfer €22,500,000.00 Euros,if interested kindly write back for more information. irenageorgia...@qq.com Irena .A. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body

Re: [PATCH v2] btrfs: test premature submount unmounting when deleting default subvolume

2015-06-03 Thread Eryu Guan
On Tue, Jun 02, 2015 at 10:05:30PM -0700, Omar Sandoval wrote: Add a regression test for a problem where attempting to delete the default subvolume would fail (as expected), but not until after all submounts under the subvolume were unmounted. Signed-off-by: Omar Sandoval osan...@osandov.com

[PATCH] btrfs: tweak key advancing condition

2015-06-03 Thread Naohiro Aota
The key advancing condition used in copy_to_sk() is loose. It can advance the key even if it reaches sk-max_*: e.g. when the max key = (512, 1024, -1) and the current key = (512, 1025, 10), it increments the offset by 1, continues hopeless search from (512, 1025, 11). This issue make ioctl() to

Re: [PATCH 1/2] btrfs-progs: avoid duplicate checks on user provided devid

2015-06-03 Thread Anand Jain
David, Kindly do not integrated this patch as of now. As I have just found that, the error reporting when the default background option is used is not completely transparent. I need to fix this before this patch. Thanks, Anand On 06/03/2015 03:49 PM, Anand Jain wrote: On 06/02/2015

Re: [GIT PULL] Send fixes for 4.2

2015-06-03 Thread Chris Mason
On 06/02/2015 11:15 PM, Filipe Manana wrote: Hi Chris, Please pull 2 fixes for the send feature from my branch send_fixes_4.2. Both have been around in the mailing list/patchwork before the 4.1 merge window opened but were not picked for 4.1. They both have tests merged in xfstests