On Fri, Oct 13, 2017 at 04:55:58PM +0300, Nikolay Borisov wrote:
>
> >
> > The outstanding_extents accounting is consistent with only the items needed
> > to
> > handle the outstanding extent items. However since changing the inode
> > requires
> > updating the inode item as well we have to
just a few quick things for the changelog:
On 09/29/2017 01:43 PM, Josef Bacik wrote:
> Right now we do a lot of weird hoops around outstanding_extents in order
> to keep the extent count consistent. This is because we logically
> transfer the outstanding_extent count from the initial
>
> The outstanding_extents accounting is consistent with only the items needed to
> handle the outstanding extent items. However since changing the inode
> requires
> updating the inode item as well we have to keep this floating reservation for
> the inode item until we have 0 outstanding
On Fri, Oct 13, 2017 at 09:10:52AM -0400, Josef Bacik wrote:
> On Fri, Oct 13, 2017 at 11:39:15AM +0300, Nikolay Borisov wrote:
> >
> >
> > On 29.09.2017 22:43, Josef Bacik wrote:
> > >
> > > +static inline void btrfs_mod_outstanding_extents(struct btrfs_inode
> > > *inode,
> > > +
On Fri, Oct 13, 2017 at 11:39:15AM +0300, Nikolay Borisov wrote:
>
>
> On 29.09.2017 22:43, Josef Bacik wrote:
> >
> > +static inline void btrfs_mod_outstanding_extents(struct btrfs_inode *inode,
> > +int mod)
> > +{
> > +
On 29.09.2017 22:43, Josef Bacik wrote:
>
> +static inline void btrfs_mod_outstanding_extents(struct btrfs_inode *inode,
> + int mod)
> +{
> + ASSERT(spin_is_locked(>lock));
> + inode->outstanding_extents += mod;
> + if
Right now we do a lot of weird hoops around outstanding_extents in order
to keep the extent count consistent. This is because we logically
transfer the outstanding_extent count from the initial reservation
through the set_delalloc_bits. This makes it pretty difficult to get a
handle on how and
