Re: [PATCH v2 10/12] Btrfs: get rid of btrfs_orphan_commit_root() and root->orphan_inodes

On Fri, May 11, 2018 at 10:01:34AM +0300, Nikolay Borisov wrote: > > > On 11.05.2018 03:11, Omar Sandoval wrote: > > From: Omar Sandoval > > > > btrfs_orphan_commit_root() tries to delete an orphan item for a > > subvolume in the tree root, but we don't actually insert that

Re: [PATCH v2 10/12] Btrfs: get rid of btrfs_orphan_commit_root() and root->orphan_inodes

On 11.05.2018 03:11, Omar Sandoval wrote: > From: Omar Sandoval > > btrfs_orphan_commit_root() tries to delete an orphan item for a > subvolume in the tree root, but we don't actually insert that item in > the first place. See commit 0a0d4415e338 ("Btrfs: delete dead code in >

Re: [PATCH v2 08/12] Btrfs: fix ENOSPC caused by orphan items reservations

On Fri, May 11, 2018 at 09:38:15AM +0300, Nikolay Borisov wrote: > > > On 11.05.2018 03:11, Omar Sandoval wrote: > > From: Omar Sandoval > > > > Currently, we keep space reserved for all inode orphan items until the > > inode is evicted (i.e., all references to it are dropped).

Re: [PATCH v2 09/12] Btrfs: get rid of root->orphan_block_rsv and root->orphan_lock

On Fri, May 11, 2018 at 09:44:36AM +0300, Nikolay Borisov wrote: > > > On 11.05.2018 03:11, Omar Sandoval wrote: > > From: Omar Sandoval > > > > Now that we don't keep long-standing reservations for orphan items, > > root->orphan_block_rsv isn't used. We can git rid of it and >

Re: [PATCH v2 09/12] Btrfs: get rid of root->orphan_block_rsv and root->orphan_lock

On 11.05.2018 03:11, Omar Sandoval wrote: > From: Omar Sandoval > > Now that we don't keep long-standing reservations for orphan items, > root->orphan_block_rsv isn't used. We can git rid of it and > root->orphan_lock, which was used to protect it. > > Signed-off-by: Omar

Re: [PATCH v2 08/12] Btrfs: fix ENOSPC caused by orphan items reservations

On 11.05.2018 03:11, Omar Sandoval wrote: > From: Omar Sandoval > > Currently, we keep space reserved for all inode orphan items until the > inode is evicted (i.e., all references to it are dropped). We hit an > issue where an application would keep a bunch of deleted files

[PATCH v2] btrfs: incremental send, fix BUG when invalid memory access

From: Robbie Ko [BUG] btrfs incremental send BUG happens when creating a snapshot of snapshot that is being used by send. [REASON] The problem can happen if while we are doing a send one of the snapshots used (parent or send) is snapshotted, because snapshoting implies

[PATCH 1/3] fs: add initial bh_result->b_private value to __blockdev_direct_IO()

From: Omar Sandoval Btrfs abuses current->journal_info in btrfs_direct_IO() in order to pass around some state to get_block() and submit_io(). The generic DIO code already provides bh_result->b_private as a way to pass data between calls to get_block() and end_io(), but it is

[PATCH 0/3] Btrfs: stop abusing current->journal_info for direct I/O

From: Omar Sandoval Hi, everyone, Btrfs currently abuses current->journal_info in btrfs_direct_IO() in order to pass around some state to get_block() and submit_io(). This hack is ugly and unnecessary because the data we pass around is only used in one call frame. Robbie Ko also

[PATCH 3/3] Btrfs: stop abusing current->journal_info in btrfs_direct_IO()

From: Omar Sandoval Now that we can pass around the struct btrfs_dio_data through the different callbacks generically, we don't need to shove it in current->journal_info. Signed-off-by: Omar Sandoval --- fs/btrfs/inode.c | 33 +++--

[PATCH 2/3] fs: add private argument to dio_submit_t

From: Omar Sandoval get_block() already has access to this through bh_result->b_private, and it gets passed to end_io() as private, so do the same for submit_io(). Along with the previous change, this will allow us to get rid Btrfs' current->journal_info abuse in

<    1   2