Message ID | 4B22D029.5090304@redhat.com |
---|---|
State | Accepted, archived |
Headers | show |
> ext4, at least, would like to start pushing on writeback if it starts > to get close to ENOSPC when reserving worst-case blocks for delalloc > writes. Writing out delalloc data will convert those worst-case > predictions into usually smaller actual usage, freeing up space > before we hit ENOSPC based on this speculation. > > Thanks to Jens for the suggestion for the helper function, > & the naming help. > > I've made the helper return status on whether writeback was > started even though I don't plan to use it in the ext4 patch; > it seems like it would be potentially useful to test this > in some cases. > > Signed-off-by: Eric Sandeen <sandeen@redhat.com> The patch looks good. Acked-by: Jan Kara <jack@suse.cz> Honza > --- > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > index 9d5360c..bff5f77 100644 > --- a/fs/fs-writeback.c > +++ b/fs/fs-writeback.c > @@ -1213,6 +1213,23 @@ void writeback_inodes_sb(struct super_block *sb) > EXPORT_SYMBOL(writeback_inodes_sb); > > /** > + * writeback_inodes_sb_if_idle - start writeback if none underway > + * @sb: the superblock > + * > + * Invoke writeback_inodes_sb if no writeback is currently underway. > + * Returns 1 if writeback was started, 0 if not. > + */ > +int writeback_inodes_sb_if_idle(struct super_block *sb) > +{ > + if (!writeback_in_progress(sb->s_bdi)) { > + writeback_inodes_sb(sb); > + return 1; > + } else > + return 0; > +} > +EXPORT_SYMBOL(writeback_inodes_sb_if_idle); > + > +/** > * sync_inodes_sb - sync sb inode pages > * @sb: the superblock > * > diff --git a/include/linux/writeback.h b/include/linux/writeback.h > index 66ebddc..dc52482 100644 > --- a/include/linux/writeback.h > +++ b/include/linux/writeback.h > @@ -69,6 +69,7 @@ struct writeback_control { > struct bdi_writeback; > int inode_wait(void *); > void writeback_inodes_sb(struct super_block *); > +int writeback_inodes_sb_if_idle(struct super_block *); > void sync_inodes_sb(struct super_block *); > void writeback_inodes_wbc(struct writeback_control *wbc); > long wb_do_writeback(struct bdi_writeback *wb, int force_wait); > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Dec 11 2009, Eric Sandeen wrote: > ext4, at least, would like to start pushing on writeback if it starts > to get close to ENOSPC when reserving worst-case blocks for delalloc > writes. Writing out delalloc data will convert those worst-case > predictions into usually smaller actual usage, freeing up space > before we hit ENOSPC based on this speculation. > > Thanks to Jens for the suggestion for the helper function, > & the naming help. > > I've made the helper return status on whether writeback was > started even though I don't plan to use it in the ext4 patch; > it seems like it would be potentially useful to test this > in some cases. Eric, how do you want to merge these? I can easily take this first one through any branch, but I suppose the ext4 one should go through the proper ext4 channels.
Jens Axboe wrote: > On Fri, Dec 11 2009, Eric Sandeen wrote: >> ext4, at least, would like to start pushing on writeback if it starts >> to get close to ENOSPC when reserving worst-case blocks for delalloc >> writes. Writing out delalloc data will convert those worst-case >> predictions into usually smaller actual usage, freeing up space >> before we hit ENOSPC based on this speculation. >> >> Thanks to Jens for the suggestion for the helper function, >> & the naming help. >> >> I've made the helper return status on whether writeback was >> started even though I don't plan to use it in the ext4 patch; >> it seems like it would be potentially useful to test this >> in some cases. > > Eric, how do you want to merge these? I can easily take this first one > through any branch, but I suppose the ext4 one should go through the > proper ext4 channels. Doesn't matter to me really; maybe it'd be simpler if it all went though the ext4 tree so that there aren't any ordering problems? -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Dec 18 2009, Eric Sandeen wrote: > Jens Axboe wrote: > > On Fri, Dec 11 2009, Eric Sandeen wrote: > >> ext4, at least, would like to start pushing on writeback if it starts > >> to get close to ENOSPC when reserving worst-case blocks for delalloc > >> writes. Writing out delalloc data will convert those worst-case > >> predictions into usually smaller actual usage, freeing up space > >> before we hit ENOSPC based on this speculation. > >> > >> Thanks to Jens for the suggestion for the helper function, > >> & the naming help. > >> > >> I've made the helper return status on whether writeback was > >> started even though I don't plan to use it in the ext4 patch; > >> it seems like it would be potentially useful to test this > >> in some cases. > > > > Eric, how do you want to merge these? I can easily take this first one > > through any branch, but I suppose the ext4 one should go through the > > proper ext4 channels. > > Doesn't matter to me really; maybe it'd be simpler if it all went > though the ext4 tree so that there aren't any ordering problems? Definately :-)
On Fri, Dec 18, 2009 at 04:33:36PM +0100, Jens Axboe wrote: > > Doesn't matter to me really; maybe it'd be simpler if it all went > > though the ext4 tree so that there aren't any ordering problems? > > Definately :-) Thanks, I've added them to the ext4 patch queue. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 9d5360c..bff5f77 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -1213,6 +1213,23 @@ void writeback_inodes_sb(struct super_block *sb) EXPORT_SYMBOL(writeback_inodes_sb); /** + * writeback_inodes_sb_if_idle - start writeback if none underway + * @sb: the superblock + * + * Invoke writeback_inodes_sb if no writeback is currently underway. + * Returns 1 if writeback was started, 0 if not. + */ +int writeback_inodes_sb_if_idle(struct super_block *sb) +{ + if (!writeback_in_progress(sb->s_bdi)) { + writeback_inodes_sb(sb); + return 1; + } else + return 0; +} +EXPORT_SYMBOL(writeback_inodes_sb_if_idle); + +/** * sync_inodes_sb - sync sb inode pages * @sb: the superblock * diff --git a/include/linux/writeback.h b/include/linux/writeback.h index 66ebddc..dc52482 100644 --- a/include/linux/writeback.h +++ b/include/linux/writeback.h @@ -69,6 +69,7 @@ struct writeback_control { struct bdi_writeback; int inode_wait(void *); void writeback_inodes_sb(struct super_block *); +int writeback_inodes_sb_if_idle(struct super_block *); void sync_inodes_sb(struct super_block *); void writeback_inodes_wbc(struct writeback_control *wbc); long wb_do_writeback(struct bdi_writeback *wb, int force_wait);
ext4, at least, would like to start pushing on writeback if it starts to get close to ENOSPC when reserving worst-case blocks for delalloc writes. Writing out delalloc data will convert those worst-case predictions into usually smaller actual usage, freeing up space before we hit ENOSPC based on this speculation. Thanks to Jens for the suggestion for the helper function, & the naming help. I've made the helper return status on whether writeback was started even though I don't plan to use it in the ext4 patch; it seems like it would be potentially useful to test this in some cases. Signed-off-by: Eric Sandeen <sandeen@redhat.com> --- -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html