| Message ID | 1416675267-2191-4-git-send-email-tytso@mit.edu (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Sat, Nov 22 2014, Theodore Ts'o <tytso@mit.edu> wrote: > Guarantee that the on-disk timestamps will be no more than 24 hours > stale. > > static int update_time(struct inode *inode, struct timespec *time, int flags) > { > + unsigned short days_since_boot = jiffies / (HZ * 86400); > int ret; > This seems to wrap every 49 days (assuming 32 bit jiffies and HZ==1000), so on-disk updates can be delayed indefinitely, assuming just the right delays between writes. > if (inode->i_op->update_time) { > @@ -1527,14 +1528,27 @@ static int update_time(struct inode *inode, struct timespec *time, int flags) > if (flags & S_MTIME) > inode->i_mtime = *time; > } > - if (inode->i_sb->s_flags & MS_LAZYTIME) { > + /* > + * If i_ts_dirty_day is zero, then either we have not deferred > + * timestamp updates, or the system has been up for less than > + * a day (so days_since_boot is zero), so we defer timestamp > + * updates in that case and set the I_DIRTY_TIME flag. If a > + * day or more has passed, then i_ts_dirty_day will be > + * different from days_since_boot, and then we should update > + * the on-disk inode and then we can clear i_ts_dirty_day. > + */ AFAICT days_since_boot is not actually 0 immediately after boot due to #define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ)) On 32 bit platforms, days_since_boot will be 0 shortly after, while on 64 bit it will always be >= 49. Not exactly sure how this affects the above logic. Would it make sense to introduce days_since_boot as a global variable and avoid these issues? This would presumably also make update_time a few cycles faster (avoiding a division-by-constant), but not sure if that's important. And something of course needs to update days_since_boot, but that should be doable. Rasmus -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 24, 2014 at 01:27:21PM +0100, Rasmus Villemoes wrote: > On Sat, Nov 22 2014, Theodore Ts'o <tytso@mit.edu> wrote: > > > Guarantee that the on-disk timestamps will be no more than 24 hours > > stale. > > > > + unsigned short days_since_boot = jiffies / (HZ * 86400); > > This seems to wrap every 49 days (assuming 32 bit jiffies and HZ==1000), > so on-disk updates can be delayed indefinitely, assuming just the right > delays between writes. Good point, I'll fix this. > Would it make sense to introduce days_since_boot as a global variable > and avoid these issues? This would presumably also make update_time a > few cycles faster (avoiding a division-by-constant), but not sure if > that's important. And something of course needs to update > days_since_boot, but that should be doable. I can do this fairly simply like this: get_monotonic_boottime(&uptime); daycode = uptime.tv_sec / (HZ * 86400); and we only need to do this if lazytime is set, and the inode isn't marked as I_DIRTY_TIME: if ((inode->i_sb->s_flags & MS_LAZYTIME) && !(flags & S_VERSION)) { if (inode->i_state & I_DIRTY_TIME) return 0; get_monotonic_boottime(&uptime); daycode = do_div64(uptime.tv_sec do_div, (HZ * 86400)); if (!inode->i_ts_dirty_day || inode->i_ts_dirty_day == daycode) { spin_lock(&inode->i_lock); inode->i_state |= I_DIRTY_TIME; spin_unlock(&inode->i_lock); inode->i_ts_dirty_day = daycode; return 0; } } So I'm not entirely sure it's worth it to create a global variable for days since boot; I've been runnin with this patch in my laptop, we wouldn't be triggering the get_monotonic_bootime() function all that often. (Since once the dirty_time flg is set, we don't need to check about whether we need to set it again.) And if we *did* care, it would be simple enough to use a static counter which only recalculates daycode every 30 or 60 minutes. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" 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 ce7de22..eb04277 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -1141,6 +1141,7 @@ void __mark_inode_dirty(struct inode *inode, int flags) if (flags & (I_DIRTY_SYNC | I_DIRTY_DATASYNC)) { trace_writeback_dirty_inode_start(inode, flags); + inode->i_ts_dirty_day = 0; if (sb->s_op->dirty_inode) sb->s_op->dirty_inode(inode, flags); diff --git a/fs/inode.c b/fs/inode.c index 11fe81b..0d939a8 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -1511,6 +1511,7 @@ static int relatime_need_update(struct vfsmount *mnt, struct inode *inode, */ static int update_time(struct inode *inode, struct timespec *time, int flags) { + unsigned short days_since_boot = jiffies / (HZ * 86400); int ret; if (inode->i_op->update_time) { @@ -1527,14 +1528,27 @@ static int update_time(struct inode *inode, struct timespec *time, int flags) if (flags & S_MTIME) inode->i_mtime = *time; } - if (inode->i_sb->s_flags & MS_LAZYTIME) { + /* + * If i_ts_dirty_day is zero, then either we have not deferred + * timestamp updates, or the system has been up for less than + * a day (so days_since_boot is zero), so we defer timestamp + * updates in that case and set the I_DIRTY_TIME flag. If a + * day or more has passed, then i_ts_dirty_day will be + * different from days_since_boot, and then we should update + * the on-disk inode and then we can clear i_ts_dirty_day. + */ + if ((inode->i_sb->s_flags & MS_LAZYTIME) && + (!inode->i_ts_dirty_day || + inode->i_ts_dirty_day == days_since_boot)) { if (inode->i_state & I_DIRTY_TIME) return 0; spin_lock(&inode->i_lock); inode->i_state |= I_DIRTY_TIME; spin_unlock(&inode->i_lock); + inode->i_ts_dirty_day = days_since_boot; return 0; } + inode->i_ts_dirty_day = 0; if (inode->i_op->write_time) return inode->i_op->write_time(inode); mark_inode_dirty_sync(inode); diff --git a/include/linux/fs.h b/include/linux/fs.h index 489b2f2..e3574cd 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -575,6 +575,7 @@ struct inode { struct timespec i_ctime; spinlock_t i_lock; /* i_blocks, i_bytes, maybe i_size */ unsigned short i_bytes; + unsigned short i_ts_dirty_day; unsigned int i_blkbits; blkcnt_t i_blocks;
Guarantee that the on-disk timestamps will be no more than 24 hours stale. Signed-off-by: Theodore Ts'o <tytso@mit.edu> --- fs/fs-writeback.c | 1 + fs/inode.c | 16 +++++++++++++++- include/linux/fs.h | 1 + 3 files changed, 17 insertions(+), 1 deletion(-)