[PATCH] btrfs: trival fix of __btrfs_set_acl error handling

* If the allocation failed, don't free to free it, even though kfree allows to free a NULL pointer. * If posix_acl_to_xattr() failed, cleanup the allocation and return the error directly. Signed-off-by: Sheng Yong --- fs/btrfs/acl.c | 14 +++--- 1 file

Re: [PATCH] btrfs: trival fix of __btrfs_set_acl error handling

Hi, Qu On 9/8/2015 4:50 PM, Qu Wenruo wrote: > Sheng Yong wrote on 2015/09/08 08:46 +: >> * If the allocation failed, don't free to free it, even though kfree >>allows to free a NULL pointer. >> * If posix_acl_to_xattr() failed, cleanup the allocation and return >>the error directly.

[PATCH 05/19] btrfs: qgroup: Introduce function to reserve data range per inode

Introduce new function reserve_data_range(). This function will find non-overlap range and to insert it into reserve map using previously introduced functions. This provides the basis for later per inode reserve map implement. Signed-off-by: Qu Wenruo ---

Re: [PATCH RFC 00/14] Accurate qgroup reserve framework

Sorry for the confusing cover letter title. This patch is no longer RFC now. It's already a working one, and we're doing stress test to ensure it's completely OK, but seems quite good for now. To Chris, I know the timing I sent the patchset is quite awful, as there is only less than 1 week

[PATCH 08/19] btrfs: qgroup: Introduce function to release/free reserved data range

Introduce functions btrfs_qgroup_release/free_data() to release/free reserved data range. Release means, just remove the data range from data rsv map, but doesn't free the reserved space. This is for normal buffered write case, when data is written into disc and its metadata is added into tree,

[PATCH 13/19] btrfs: extent-tree: Add new verions of btrfs_check_data_free_space

Add new function __btrfs_check_data_free_space() to do precious space reservation. The new function will replace old btrfs_check_data_free_space(), but until all the change is done, let's just use the new name. Also, export internal use function btrfs_alloc_data_chunk_ondemand(), as now qgroup

[PATCH 15/19] btrfs: fallocate: Add support to accurate qgroup reserve

Now fallocate will do accurate qgroup reserve space check, unlike old method, which will always reserve the whole length of the range. With this patch, fallocate will: 1) Iterate the desired range and mark in data rsv map Only range which is going to be allocated will be recorded in data

[PATCH 12/19] btrfs: qgroup: Use new metadata reservation.

As we have the new metadata reservation functions, use them to replace the old btrfs_qgroup_reserve() call for metadata. Signed-off-by: Qu Wenruo --- fs/btrfs/extent-tree.c | 14 ++ fs/btrfs/transaction.c | 34 ++

[PATCH 14/19] btrfs: Switch to new check_data_free_space

Use new check_data_free_space for buffered write and inode cache. For buffered write case, as nodatacow write won't increase quota account, so unlike old behavior which does reserve before check nocow, now we check nocow first and then only reserve data if we can't do nocow write. Signed-off-by:

Re: [PATCH] btrfs: trival fix of __btrfs_set_acl error handling

Sheng Yong wrote on 2015/09/08 08:46 +: * If the allocation failed, don't free to free it, even though kfree allows to free a NULL pointer. * If posix_acl_to_xattr() failed, cleanup the allocation and return the error directly. So, what's the point? For me, I didn't see the pros of

[PATCH 09/19] btrfs: delayed_ref: Add new function to record reserved space into delayed ref

Add new function btrfs_add_delayed_qgroup_reserve() function to record how much space is reserved for that extent. As btrfs only accounts qgroup at run_delayed_refs() time, so newly allocated extent should keep the reserved space until then. So add needed function with related members to do it.

[PATCH 11/19] btrfs: qgroup: Introduce new functions to reserve/free metadata

Introduce new functions btrfs_qgroup_reserve/free_meta() to reserve/free metadata reserved space. Signed-off-by: Qu Wenruo --- fs/btrfs/ctree.h | 3 +++ fs/btrfs/disk-io.c | 1 + fs/btrfs/qgroup.c | 40 fs/btrfs/qgroup.h |

[PATCH 10/19] btrfs: delayed_ref: release and free qgroup reserved at proper timing

Qgroup reserved space needs to be released from inode dirty map and get freed at different timing: 1) Release when the metadata is written into tree After corresponding metadata is written into tree, any newer write will be COWed(don't include NOCOW case yet). So we must release its range from

[PATCH 17/19] btrfs: extent-tree: Use new __btrfs_delalloc_reserve_space function

Use new __btrfs_delalloc_reserve_space to reserve space. Signed-off-by: Qu Wenruo --- fs/btrfs/inode-map.c | 2 +- fs/btrfs/inode.c | 16 ++-- fs/btrfs/ioctl.c | 5 +++-- 3 files changed, 14 insertions(+), 9 deletions(-) diff --git

[PATCH 19/19] btrfs: qgroup: Add handler for NOCOW and inline

For NOCOW and inline case, there will be no delayed_ref created for them, so we should free their reserved data space at proper time(finish_ordered_io for NOCOW and cow_file_inline for inline). Signed-off-by: Qu Wenruo --- fs/btrfs/extent-tree.c | 7 ++-

[PATCH 18/19] btrfs: qgroup: Cleanup old inaccurate facilities

Cleanup the old facilities which use old btrfs_qgroup_reserve() function call, replace them with the newer version, and remove the "__" prefix in them. Also, make btrfs_qgroup_reserve/free() functions private, as they are now only used inside qgroup codes. Now, the whole btrfs qgroup is swithed

[PATCH 16/19] btrfs: extent-tree: Add new version of btrfs_delalloc_reserve_space

Add new version of btrfs_delalloc_reserve_space() function, which supports accurate qgroup reserve. Signed-off-by: Qu Wenruo --- fs/btrfs/ctree.h | 1 + fs/btrfs/extent-tree.c | 38 ++ 2 files changed, 39 insertions(+) diff

[PATCH 04/19] btrfs: qgroup: Introduce function to insert non-overlap reserve range

New function insert_data_ranges() will insert non-overlap reserve ranges into reserve map. It provides the basis for later qgroup reserve map implement. Signed-off-by: Qu Wenruo --- fs/btrfs/qgroup.c | 124 ++ 1 file

[PATCH 06/19] btrfs: qgroup: Introduce btrfs_qgroup_reserve_data function

This new function will do all the hard work to reserve precious space for a write. The overall work flow will be the following. File A already has some dirty pages: 0 4K 8K 12K 16K |///| |///| And then, someone want to write some data into range [4K, 16K).

[PATCH 07/19] btrfs: qgroup: Introduce function to release reserved range

Introduce new function release_data_range() to release reserved ranges. It will iterate through all existing ranges and remove/shrink them. Note this function will not free reserved space, as the range can be released in the following conditions: 1) The dirty range gets written to disk. In

[PATCH RFC 00/14] Accurate qgroup reserve framework

[[BUG]] One of the most common case to trigger the bug is the following method: 1) Enable quota 2) Limit excl of qgroup 5 to 16M 3) Write [0,2M) of a file inside subvol 5 10 times without sync EQUOT will be triggered at about the 8th write. [[CAUSE]] The problem is caused by the fact that qgroup

[PATCH 01/19] btrfs: qgroup: New function declaration for new reserve implement

Add new structures and functions for new qgroup reserve implement dirty phase. Which will focus on avoiding over-reserve as in that case, which means for already reserved dirty space range, we won't reserve space again. This patch adds the needed structure declaration and comments.

[PATCH 02/19] btrfs: qgroup: Implement data_rsv_map init/free functions

New functions btrfs_qgroup_init/free_data_rsv_map() to init/free data reserve map. Data reserve map is used to mark which range already holds reserved space, to avoid current reserved space leak. Signed-off-by: Qu Wenruo --- fs/btrfs/btrfs_inode.h | 2 ++

[PATCH 03/19] btrfs: qgroup: Introduce new function to search most left reserve range

Introduce the new function to search the most left reserve range in a reserve map. It provides the basis for later reserve map implement. Signed-off-by: Qu Wenruo --- fs/btrfs/qgroup.c | 36 1 file changed, 36 insertions(+) diff

Re: raid6 + hot spare question

On Tue, Sep 08, 2015 at 01:59:19PM +0200, Peter Keše wrote: > > I'm planning to set up a raid6 array with 4 x 4TB drives. > Presumably that would result in 8TB of usable space + parity, which > is about enough for my data (my data is currently 5TB in raid1, > slowly growing at about 1 TB per

Re: [PATCH] btrfs: trival fix of __btrfs_set_acl error handling

On Tue, Sep 08, 2015 at 05:02:32PM +0800, Sheng Yong wrote: > Hi, Qu > > On 9/8/2015 4:50 PM, Qu Wenruo wrote: > > Sheng Yong wrote on 2015/09/08 08:46 +: > >> * If the allocation failed, don't free to free it, even though kfree > >>allows to free a NULL pointer. > >> * If

raid6 + hot spare question

I'm planning to set up a raid6 array with 4 x 4TB drives. Presumably that would result in 8TB of usable space + parity, which is about enough for my data (my data is currently 5TB in raid1, slowly growing at about 1 TB per year, but I often keep some additional backups if space permits).

[PATCH v9.1 1/3] xfstests: btrfs: add functions to create dm-error device

From: Anand Jain Controlled EIO from the device is achieved using the dm device. Helper functions are at common/dmerror. Broadly steps will include calling _dmerror_init(). _dmerror_init() will use SCRATCH_DEV to create dm linear device and assign DMERROR_DEV to

Re: [PATCH] btrfs-progs: makefile: drop u option from ar invocation

On Sat, Sep 05, 2015 at 01:06:18AM +0200, Arnd Hannemann wrote: > In newer distros (ubuntu 15.10, fedora rawhide) the binutils > ar uses the new D flag per default to build deterministic > binaries. > Without this patch the following warning is issued, when > building btrfs-progs: > > [AR]

Re: [btrfs tools] ability to fail a device...

On 8 September 2015 at 21:43, Ian Kumlien wrote: > On 8 September 2015 at 21:34, Hugo Mills wrote: >> On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote: [--8<--] >>Physically removing it is the way to go (or disabling it using echo >>

RE: mkfs.btrfs cannot find rotational file for SSD detection for a pmem device

> -Original Message- > From: Austin S Hemmelgarn [mailto:ahferro...@gmail.com] > Sent: Tuesday, September 8, 2015 7:56 AM > Subject: Re: mkfs.btrfs cannot find rotational file for SSD detection for > a pmem device > > On 2015-09-06 13:51, Elliott, Robert (Persistent Memory) wrote: ... >

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On 08/09/15 20:10, Andy Lutomirski wrote: > On Tue, Sep 8, 2015 at 11:23 AM, Anna Schumaker > wrote: >> On 09/08/2015 11:21 AM, Pádraig Brady wrote: >>> I see copy_file_range() is a reflink() on BTRFS? >>> That's a bit surprising, as it avoids the copy completely. >>>

Re: [btrfs tools] ability to fail a device...

On Tue, Sep 8, 2015 at 2:00 PM, Ian Kumlien wrote: > On 8 September 2015 at 21:55, Ian Kumlien wrote: >> On 8 September 2015 at 21:43, Ian Kumlien wrote: >>> On 8 September 2015 at 21:34, Hugo Mills wrote:

Re: [btrfs tools] ability to fail a device...

On 8 September 2015 at 22:17, Chris Murphy wrote: > On Tue, Sep 8, 2015 at 2:13 PM, Ian Kumlien wrote: >> On 8 September 2015 at 22:08, Chris Murphy wrote: >>> On Tue, Sep 8, 2015 at 2:00 PM, Ian Kumlien

Re: [btrfs tools] ability to fail a device...

On 8 September 2015 at 21:34, Hugo Mills wrote: > On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote: >> Hi, >> >> Currently i have a raid1 configuration on two disks where one of them >> is failing. >> >> But since: >> btrfs fi df /mnt/disk/ >> Data, RAID1:

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Tue, Sep 8, 2015 at 11:23 AM, Anna Schumaker wrote: > On 09/08/2015 11:21 AM, Pádraig Brady wrote: >> I see copy_file_range() is a reflink() on BTRFS? >> That's a bit surprising, as it avoids the copy completely. >> cp(1) for example considered doing a BTRFS clone by

[btrfs tools] ability to fail a device...

Hi, Currently i have a raid1 configuration on two disks where one of them is failing. But since: btrfs fi df /mnt/disk/ Data, RAID1: total=858.00GiB, used=638.16GiB Data, single: total=1.00GiB, used=256.00KiB System, RAID1: total=32.00MiB, used=132.00KiB Metadata, RAID1: total=4.00GiB,

Re: [btrfs tools] ability to fail a device...

On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote: > Hi, > > Currently i have a raid1 configuration on two disks where one of them > is failing. > > But since: > btrfs fi df /mnt/disk/ > Data, RAID1: total=858.00GiB, used=638.16GiB > Data, single: total=1.00GiB, used=256.00KiB >

Re: [btrfs tools] ability to fail a device...

On 8 September 2015 at 21:55, Ian Kumlien wrote: > On 8 September 2015 at 21:43, Ian Kumlien wrote: >> On 8 September 2015 at 21:34, Hugo Mills wrote: >>> On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote: > [--8<--] >

Re: [btrfs tools] ability to fail a device...

On 8 September 2015 at 22:08, Chris Murphy wrote: > On Tue, Sep 8, 2015 at 2:00 PM, Ian Kumlien wrote: [--8<--] >> Someone thought they were done too early, only one disk => read only >> mount. But, readonly mount => no balance. >> >> I think

Re: [btrfs tools] ability to fail a device...

On Tue, Sep 8, 2015 at 2:13 PM, Ian Kumlien wrote: > On 8 September 2015 at 22:08, Chris Murphy wrote: >> On Tue, Sep 8, 2015 at 2:00 PM, Ian Kumlien wrote: > > [--8<--] > >>> Someone thought they were done too early, only

Re: [btrfs tools] ability to fail a device...

On Tue, Sep 08, 2015 at 02:17:55PM -0600, Chris Murphy wrote: > On Tue, Sep 8, 2015 at 2:13 PM, Ian Kumlien wrote: > > On 8 September 2015 at 22:08, Chris Murphy wrote: > >> On Tue, Sep 8, 2015 at 2:00 PM, Ian Kumlien wrote:

Re: [btrfs tools] ability to fail a device...

On 8 September 2015 at 22:28, Hugo Mills wrote: > On Tue, Sep 08, 2015 at 02:17:55PM -0600, Chris Murphy wrote: >> On Tue, Sep 8, 2015 at 2:13 PM, Ian Kumlien wrote: >> > On 8 September 2015 at 22:08, Chris Murphy wrote: >> >>

Re: [btrfs tools] ability to fail a device...

On Tue, Sep 08, 2015 at 10:33:54PM +0200, Ian Kumlien wrote: > On 8 September 2015 at 22:28, Hugo Mills wrote: > > On Tue, Sep 08, 2015 at 02:17:55PM -0600, Chris Murphy wrote: > >> On Tue, Sep 8, 2015 at 2:13 PM, Ian Kumlien wrote: > >> > On 8

[PATCH] btrfs: use a single if() statement for one outcome in get_block_rsv()

Rather than have three separate if() statements for the same outcome we should just OR them together in the same if() statement. Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> --- fs/btrfs/extent-tree.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On 09/08/2015 04:45 PM, Darrick J. Wong wrote: > On Tue, Sep 08, 2015 at 11:08:03AM -0400, Anna Schumaker wrote: >> On 09/05/2015 04:33 AM, Al Viro wrote: >>> On Fri, Sep 04, 2015 at 04:25:27PM -0600, Andreas Dilger wrote: >>> This is a bit of a surprising result, since in my testing in the

Re: [PATCH v1 9/8] copy_file_range.2: New page documenting copy_file_range()

On Tue, Sep 08, 2015 at 11:04:03AM -0400, Anna Schumaker wrote: > On 09/04/2015 05:38 PM, Darrick J. Wong wrote: > > On Fri, Sep 04, 2015 at 04:17:03PM -0400, Anna Schumaker wrote: > >> copy_file_range() is a new system call for copying ranges of data > >> completely in the kernel. This gives

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Tue, Sep 08, 2015 at 11:08:03AM -0400, Anna Schumaker wrote: > On 09/05/2015 04:33 AM, Al Viro wrote: > > On Fri, Sep 04, 2015 at 04:25:27PM -0600, Andreas Dilger wrote: > > > >> This is a bit of a surprising result, since in my testing in the > >> past, copy_{to/from}_user() is a major

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Tue, Sep 08, 2015 at 09:03:09PM +0100, Pádraig Brady wrote: > On 08/09/15 20:10, Andy Lutomirski wrote: > > On Tue, Sep 8, 2015 at 11:23 AM, Anna Schumaker > > wrote: > >> On 09/08/2015 11:21 AM, Pádraig Brady wrote: > >>> I see copy_file_range() is a reflink() on

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote: > On Tue, Sep 8, 2015 at 2:29 PM, Darrick J. Wong > wrote: > > On Tue, Sep 08, 2015 at 09:03:09PM +0100, Pádraig Brady wrote: > >> On 08/09/15 20:10, Andy Lutomirski wrote: > >> > On Tue, Sep 8, 2015 at

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong wrote: > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote: >> On Tue, Sep 8, 2015 at 2:29 PM, Darrick J. Wong >> wrote: >> > On Tue, Sep 08, 2015 at 09:03:09PM +0100, Pádraig Brady

Re: [PATCH 01/19] btrfs: qgroup: New function declaration for new reserve implement

Hi, Qu, On 2015/09/08 17:56, Qu Wenruo wrote: > Add new structures and functions for new qgroup reserve implement dirty > phase. > Which will focus on avoiding over-reserve as in that case, which means > for already reserved dirty space range, we won't reserve space again. > > This patch adds

Re: [PATCH v1 9/8] copy_file_range.2: New page documenting copy_file_range()

On 09/04/2015 05:38 PM, Darrick J. Wong wrote: > On Fri, Sep 04, 2015 at 04:17:03PM -0400, Anna Schumaker wrote: >> copy_file_range() is a new system call for copying ranges of data >> completely in the kernel. This gives filesystems an opportunity to >> implement some kind of "copy

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On 04/09/15 21:16, Anna Schumaker wrote: > Copy system calls came up during Plumbers a couple of weeks ago, because > several filesystems (including NFS and XFS) are currently working on copy > acceleration implementations. We haven't heard from Zach Brown in a while, > so I volunteered to push

Re: [PATCH 10/19] btrfs: delayed_ref: release and free qgroup reserved at proper timing

Tsutomu Itoh wrote on 2015/09/09 10:21 +0900: Hi, Qu, On 2015/09/08 18:08, Qu Wenruo wrote: Qgroup reserved space needs to be released from inode dirty map and get freed at different timing: 1) Release when the metadata is written into tree After corresponding metadata is written into tree,

Re: [PATCH 3/3] btrfs-progs: tests: Introduce misc-tests/008-leaf-accross-stripes

Zhao Lei wrote on 2015/09/04 21:23 +0800: To check is btrfs-convert create bad filesystem with leaf accross stripes. It is happened in progs version <=v4.1.2, and fixed by patch titled: btrfs: convert: Avoid allocating metadata extent crossing stripe boundary which was merged in v4.2. Notice

Re: [PATCH 08/19] btrfs: qgroup: Introduce function to release/free reserved data range

Hi, Qu, On 2015/09/08 18:08, Qu Wenruo wrote: > Introduce functions btrfs_qgroup_release/free_data() to release/free > reserved data range. > > Release means, just remove the data range from data rsv map, but doesn't > free the reserved space. > This is for normal buffered write case, when data

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote: > On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong > wrote: > > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote: > >> On Tue, Sep 8, 2015 at 2:29 PM, Darrick J. Wong

Re: [PATCH 10/19] btrfs: delayed_ref: release and free qgroup reserved at proper timing

Hi, Qu, On 2015/09/08 18:08, Qu Wenruo wrote: > Qgroup reserved space needs to be released from inode dirty map and get > freed at different timing: > > 1) Release when the metadata is written into tree > After corresponding metadata is written into tree, any newer write will > be COWed(don't

Re: [PATCH 04/19] btrfs: qgroup: Introduce function to insert non-overlap reserve range

Hi, Qu, On 2015/09/08 18:01, Qu Wenruo wrote: > New function insert_data_ranges() will insert non-overlap reserve ranges > into reserve map. > > It provides the basis for later qgroup reserve map implement. > > Signed-off-by: Qu Wenruo > --- > fs/btrfs/qgroup.c | 124

Re: Btrfs progs release 4.1

Hi David, Sorry for the late reply, but I noticed something interesting. David Sterba wrote on 2015/06/22 17:00 +0200: Hi, btrfs-progs 4.1 have been released (in time with kernel 4.1). Unusual load of changes. Fixed since rc1: - uuid rewrite prints the correct original UUID -

Re: [PATCH 13/19] btrfs: extent-tree: Add new verions of btrfs_check_data_free_space

Hi, Qu, On 2015/09/08 18:22, Qu Wenruo wrote: > Add new function __btrfs_check_data_free_space() to do precious space > reservation. > > The new function will replace old btrfs_check_data_free_space(), but > until all the change is done, let's just use the new name. > > Also, export internal

Re: [btrfs tools] ability to fail a device...

On 09/09/2015 03:34 AM, Hugo Mills wrote: On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote: Hi, Currently i have a raid1 configuration on two disks where one of them is failing. But since: btrfs fi df /mnt/disk/ Data, RAID1: total=858.00GiB, used=638.16GiB Data, single:

Re: [PATCH 18/19] btrfs: qgroup: Cleanup old inaccurate facilities

Hi, Qu, On 2015/09/08 18:25, Qu Wenruo wrote: > Cleanup the old facilities which use old btrfs_qgroup_reserve() function > call, replace them with the newer version, and remove the "__" prefix in > them. > > Also, make btrfs_qgroup_reserve/free() functions private, as they are > now only used

Re: Btrfs progs release 4.1

Qu Wenruo wrote on 2015/09/09 09:34 +0800: Hi David, Sorry for the late reply, but I noticed something interesting. David Sterba wrote on 2015/06/22 17:00 +0200: Hi, btrfs-progs 4.1 have been released (in time with kernel 4.1). Unusual load of changes. Fixed since rc1: - uuid rewrite

Re: [PATCH v1 9/8] copy_file_range.2: New page documenting copy_file_range()

On 09/04/2015 06:31 PM, Andreas Dilger wrote: > On Sep 4, 2015, at 3:38 PM, Darrick J. Wong wrote: >> >> On Fri, Sep 04, 2015 at 04:17:03PM -0400, Anna Schumaker wrote: >>> copy_file_range() is a new system call for copying ranges of data >>> completely in the kernel.

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On 09/04/2015 06:25 PM, Andreas Dilger wrote: > On Sep 4, 2015, at 2:16 PM, Anna Schumaker wrote: >> >> Copy system calls came up during Plumbers a couple of weeks ago, >> because several filesystems (including NFS and XFS) are currently >> working on copy acceleration

[PATCH 2/3] btrfs-progs: Avoid uninitialized data in output of btrfs-convert

sequence, transid and reserved field of inode was write to disk with uninitizlized value, this patch fixed it. Signed-off-by: Zhao Lei --- btrfs-convert.c | 4 ctree.h | 2 ++ 2 files changed, 6 insertions(+) diff --git a/btrfs-convert.c b/btrfs-convert.c

[PATCH 1/3] btrfs-progs: fix set_get typo of btrfs_inode_item->sequence

s/generation/sequence for BTRFS_SETGET_STACK_FUNCS(stack_inode_sequence, ...) Signed-off-by: Zhao Lei --- ctree.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ctree.h b/ctree.h index bcad2b9..2061e1e 100644 --- a/ctree.h +++ b/ctree.h @@ -1423,7

[PATCH 3/3] btrfs-progs: add ext2fs_close_inode_scan to copy_inodes

We need use ext2fs_close_inode_scan to release relative resource get from ext2fs_open_inode_scan() in copy_inodes() Signed-off-by: Zhao Lei --- btrfs-convert.c | 1 + 1 file changed, 1 insertion(+) diff --git a/btrfs-convert.c b/btrfs-convert.c index 934f4dc..e7f3c9e

[PATCH RFC 00/14] Accurate qgroup reserve framework

[[BUG]] One of the most common case to trigger the bug is the following method: 1) Enable quota 2) Limit excl of qgroup 5 to 16M 3) Write [0,2M) of a file inside subvol 5 10 times without sync EQUOT will be triggered at about the 8th write. [[CAUSE]] The problem is caused by the fact that qgroup

[PATCH 17/19] btrfs: extent-tree: Use new __btrfs_delalloc_reserve_space function

Use new __btrfs_delalloc_reserve_space to reserve space. Signed-off-by: Qu Wenruo --- fs/btrfs/inode-map.c | 2 +- fs/btrfs/inode.c | 16 ++-- fs/btrfs/ioctl.c | 5 +++-- 3 files changed, 14 insertions(+), 9 deletions(-) diff --git

[PATCH 16/19] btrfs: extent-tree: Add new version of btrfs_delalloc_reserve_space

Add new version of btrfs_delalloc_reserve_space() function, which supports accurate qgroup reserve. Signed-off-by: Qu Wenruo --- fs/btrfs/ctree.h | 1 + fs/btrfs/extent-tree.c | 38 ++ 2 files changed, 39 insertions(+) diff

[PATCH 14/19] btrfs: Switch to new check_data_free_space

Use new check_data_free_space for buffered write and inode cache. For buffered write case, as nodatacow write won't increase quota account, so unlike old behavior which does reserve before check nocow, now we check nocow first and then only reserve data if we can't do nocow write. Signed-off-by:

[PATCH 11/19] btrfs: qgroup: Introduce new functions to reserve/free metadata

Introduce new functions btrfs_qgroup_reserve/free_meta() to reserve/free metadata reserved space. Signed-off-by: Qu Wenruo --- fs/btrfs/ctree.h | 3 +++ fs/btrfs/disk-io.c | 1 + fs/btrfs/qgroup.c | 40 fs/btrfs/qgroup.h |

[PATCH 13/19] btrfs: extent-tree: Add new verions of btrfs_check_data_free_space

Add new function __btrfs_check_data_free_space() to do precious space reservation. The new function will replace old btrfs_check_data_free_space(), but until all the change is done, let's just use the new name. Also, export internal use function btrfs_alloc_data_chunk_ondemand(), as now qgroup

[PATCH 12/19] btrfs: qgroup: Use new metadata reservation.

As we have the new metadata reservation functions, use them to replace the old btrfs_qgroup_reserve() call for metadata. Signed-off-by: Qu Wenruo --- fs/btrfs/extent-tree.c | 14 ++ fs/btrfs/transaction.c | 34 ++

[PATCH 10/19] btrfs: delayed_ref: release and free qgroup reserved at proper timing

Qgroup reserved space needs to be released from inode dirty map and get freed at different timing: 1) Release when the metadata is written into tree After corresponding metadata is written into tree, any newer write will be COWed(don't include NOCOW case yet). So we must release its range from

[PATCH 07/19] btrfs: qgroup: Introduce function to release reserved range

Introduce new function release_data_range() to release reserved ranges. It will iterate through all existing ranges and remove/shrink them. Note this function will not free reserved space, as the range can be released in the following conditions: 1) The dirty range gets written to disk. In

[PATCH 09/19] btrfs: delayed_ref: Add new function to record reserved space into delayed ref

Add new function btrfs_add_delayed_qgroup_reserve() function to record how much space is reserved for that extent. As btrfs only accounts qgroup at run_delayed_refs() time, so newly allocated extent should keep the reserved space until then. So add needed function with related members to do it.

[PATCH 02/19] btrfs: qgroup: Implement data_rsv_map init/free functions

New functions btrfs_qgroup_init/free_data_rsv_map() to init/free data reserve map. Data reserve map is used to mark which range already holds reserved space, to avoid current reserved space leak. Signed-off-by: Qu Wenruo --- fs/btrfs/btrfs_inode.h | 2 ++

[PATCH 18/19] btrfs: qgroup: Cleanup old inaccurate facilities

Cleanup the old facilities which use old btrfs_qgroup_reserve() function call, replace them with the newer version, and remove the "__" prefix in them. Also, make btrfs_qgroup_reserve/free() functions private, as they are now only used inside qgroup codes. Now, the whole btrfs qgroup is swithed

[PATCH 05/19] btrfs: qgroup: Introduce function to reserve data range per inode

Introduce new function reserve_data_range(). This function will find non-overlap range and to insert it into reserve map using previously introduced functions. This provides the basis for later per inode reserve map implement. Signed-off-by: Qu Wenruo ---

[PATCH 04/19] btrfs: qgroup: Introduce function to insert non-overlap reserve range

New function insert_data_ranges() will insert non-overlap reserve ranges into reserve map. It provides the basis for later qgroup reserve map implement. Signed-off-by: Qu Wenruo --- fs/btrfs/qgroup.c | 124 ++ 1 file

[PATCH 15/19] btrfs: fallocate: Add support to accurate qgroup reserve

Now fallocate will do accurate qgroup reserve space check, unlike old method, which will always reserve the whole length of the range. With this patch, fallocate will: 1) Iterate the desired range and mark in data rsv map Only range which is going to be allocated will be recorded in data

[PATCH 19/19] btrfs: qgroup: Add handler for NOCOW and inline

For NOCOW and inline case, there will be no delayed_ref created for them, so we should free their reserved data space at proper time(finish_ordered_io for NOCOW and cow_file_inline for inline). Signed-off-by: Qu Wenruo --- fs/btrfs/extent-tree.c | 7 ++-

[PATCH 03/19] btrfs: qgroup: Introduce new function to search most left reserve range

Introduce the new function to search the most left reserve range in a reserve map. It provides the basis for later reserve map implement. Signed-off-by: Qu Wenruo --- fs/btrfs/qgroup.c | 36 1 file changed, 36 insertions(+) diff

[PATCH 08/19] btrfs: qgroup: Introduce function to release/free reserved data range

Introduce functions btrfs_qgroup_release/free_data() to release/free reserved data range. Release means, just remove the data range from data rsv map, but doesn't free the reserved space. This is for normal buffered write case, when data is written into disc and its metadata is added into tree,

[PATCH 01/19] btrfs: qgroup: New function declaration for new reserve implement

Add new structures and functions for new qgroup reserve implement dirty phase. Which will focus on avoiding over-reserve as in that case, which means for already reserved dirty space range, we won't reserve space again. This patch adds the needed structure declaration and comments.

[PATCH 06/19] btrfs: qgroup: Introduce btrfs_qgroup_reserve_data function

This new function will do all the hard work to reserve precious space for a write. The overall work flow will be the following. File A already has some dirty pages: 0 4K 8K 12K 16K |///| |///| And then, someone want to write some data into range [4K, 16K).