Is there any practical reason to prefer bind mounts or separately
mounting a subvolume?
e.g. assuming /locationA and /locationB are arbitrarily far apart in the
file system tree, is there any reason to prefer one of the following
over the other
mount -t btrfs -o subvolume=/thing /dev/sdN1 /l
On Fri, Mar 13, 2015 at 06:27:31PM +, Filipe David Manana wrote:
> > and should go to stable@ if not to 4.1-rc as it's a bug in the core of
> > qgroups. Waiting for the next merge window would not buy us anything.
>
> Well, unless I missed something, it doesn't seem to cause any real
> harm as
On Fri, Mar 13, 2015 at 7:12 PM, Josef Bacik wrote:
> My patch to properly count outstanding extents wrt MAX_EXTENT_SIZE introduced
> a
> regression when re-dirtying already dirty areas. We have logic in split to
> make
> sure we are taking the largest space into account but didn't have it for
After looking at Liu Bo's recent patch (titled
"Btrfs: fix comp_oper to get right order") I realized the search made by
qgroup_oper_exists() was buggy because its tree navigation comparison
function, comp_oper_exist(), only looks at the fields bytenr and ref_root
of a tree node, ignoring the seq fi
On Fri, Mar 13, 2015 at 12:04:30PM +0100, David Sterba wrote:
> On Wed, Mar 11, 2015 at 09:40:17PM -0700, Omar Sandoval wrote:
> > Ping. For anyone following along, it looks like commit cc87317726f8
> > ("mm: page_alloc: revert inadvertent !__GFP_FS retry behavior change")
> > reverted the commit t
My patch to properly count outstanding extents wrt MAX_EXTENT_SIZE introduced a
regression when re-dirtying already dirty areas. We have logic in split to make
sure we are taking the largest space into account but didn't have it for merge,
so it was sometimes making us think we were turning a tiny
Direct IO can easily pass in an buffer that is greater than
BTRFS_MAX_EXTENT_SIZE, so take this into account when reserving extents in the
delalloc reservation code. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/extent-tree.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --
On Fri, Mar 13, 2015 at 6:27 PM, Filipe David Manana wrote:
> On Fri, Mar 13, 2015 at 12:37 PM, David Sterba wrote:
>> On Fri, Mar 13, 2015 at 02:24:38PM +0800, Liu Bo wrote:
>>> Case (oper1->seq > oper2->seq) should differ with case (oper1->seq <
>>> oper2->seq).
>>>
>>> Signed-off-by: Liu Bo
On Fri, Mar 13, 2015 at 12:37 PM, David Sterba wrote:
> On Fri, Mar 13, 2015 at 02:24:38PM +0800, Liu Bo wrote:
>> Case (oper1->seq > oper2->seq) should differ with case (oper1->seq <
>> oper2->seq).
>>
>> Signed-off-by: Liu Bo
>
> Reviewed-by: David Sterba
Reviewed-by: Filipe Manana
>
> and
On Fri, Mar 13, 2015 at 08:37:59AM +0800, Qu Wenruo wrote:
> > On Thu, Mar 12, 2015 at 04:33:27PM +0800, Qu Wenruo wrote:
> >> Use inline functions to do such things, to improve readability.
> >
> > This has actually hiden informations behind the helper function and
> > old_refcnt and new_refcnt ca
On Tue, Feb 24, 2015 at 02:47:04AM -0800, Omar Sandoval wrote:
> This is one of the first places to give out when memory is tight. Handle
> it properly rather than with a BUG_ON.
>
> Also fix the comment about the return value, which is an ERR_PTR, not
> NULL, on error.
>
> Signed-off-by: Omar Sa
On Tue, Feb 24, 2015 at 02:47:05AM -0800, Omar Sandoval wrote:
> Consider the following interleaving of overlapping calls to
> alloc_extent_buffer:
>
> Call 1:
>
> - Successfully allocates a few pages with find_or_create_page
> - find_or_create_page fails, goto free_eb
> - Unlocks the allocated p
On Fri, Mar 13, 2015 at 1:45 AM, Qu Wenruo wrote:
> [Problem]
> Since commit fcebe4562dec83b3f8d308 ("Btrfs: rework qgroup accounting"),
> quota data update is delayed after delayed_ref calculation, and lacks
> correct protection to detect root reference which shouldn't be counted
> in current seq
On Fri, Mar 13, 2015 at 02:24:38PM +0800, Liu Bo wrote:
> Case (oper1->seq > oper2->seq) should differ with case (oper1->seq <
> oper2->seq).
>
> Signed-off-by: Liu Bo
Reviewed-by: David Sterba
and should go to stable@ if not to 4.1-rc as it's a bug in the core of
qgroups. Waiting for the nex
On Wed, Mar 11, 2015 at 09:40:17PM -0700, Omar Sandoval wrote:
> Ping. For anyone following along, it looks like commit cc87317726f8
> ("mm: page_alloc: revert inadvertent !__GFP_FS retry behavior change")
> reverted the commit that exposed these bugs. Josef said he was okay with
> taking these, wi
If we fallocate(), without the keep size flag, into an area already covered
by an extent previously fallocated, we were updating the inode's i_size but
we weren't updating the inode item in the fs/subvol tree. A following umount
+ mount would result in a loss of the inode's size (and an fsync would
On Fri, Mar 13, 2015 at 01:58:46AM -0700, Guenter Roeck wrote:
> Building alpha:allmodconfig fails with
>
> fs/btrfs/inode.c: In function 'check_direct_IO':
> fs/btrfs/inode.c:8050:2: error: implicit declaration of function
> 'iov_iter_alignment'
>
> due to a missing include file.
>
> Fixes: 37
On Fri, Mar 13, 2015 at 8:59 AM, Filipe David Manana wrote:
> On Fri, Mar 13, 2015 at 8:11 AM, Liu Bo wrote:
>> On Thu, Mar 12, 2015 at 03:36:58PM +, Filipe Manana wrote:
>>> If we fallocate(), without the keep size flag, into an area already covered
>>> by an extent previously fallocated, we
On Fri, Mar 13, 2015 at 01:58:46AM -0700, Guenter Roeck wrote:
> Building alpha:allmodconfig fails with
>
> fs/btrfs/inode.c: In function 'check_direct_IO':
> fs/btrfs/inode.c:8050:2: error: implicit declaration of function
> 'iov_iter_alignment'
>
> due to a missing include file.
>
> Fixes: 37
On Fri, Mar 13, 2015 at 8:11 AM, Liu Bo wrote:
> On Thu, Mar 12, 2015 at 03:36:58PM +, Filipe Manana wrote:
>> If we fallocate(), without the keep size flag, into an area already covered
>> by an extent previously fallocated, we were updating the inode's i_size but
>> we weren't updating the i
Building alpha:allmodconfig fails with
fs/btrfs/inode.c: In function 'check_direct_IO':
fs/btrfs/inode.c:8050:2: error: implicit declaration of function
'iov_iter_alignment'
due to a missing include file.
Fixes: 3737c63e1fb0 ("fs: move struct kiocb to fs.h")
Cc: Christoph Hellwig
Signed-off-by
On Thu, Mar 12, 2015 at 03:36:58PM +, Filipe Manana wrote:
> If we fallocate(), without the keep size flag, into an area already covered
> by an extent previously fallocated, we were updating the inode's i_size but
> we weren't updating the inode item in the fs/subvol tree. A following umount
>
22 matches
Mail list logo
