All of lore.kernel.org
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Frank Sorenson <sorenson@redhat.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH V2 1/2] fat: implement fat_update_time for inode timestamps
Date: Tue, 10 Apr 2018 07:25:14 +0900	[thread overview]
Message-ID: <87efjouiet.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <3c8c9b7b-8531-129d-62f0-fd12ca82b2ca@redhat.com> (Frank Sorenson's message of "Mon, 9 Apr 2018 11:27:40 -0500")

Frank Sorenson <sorenson@redhat.com> writes:

>>> +	} else {
>>> +		struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
>>> +		__le16 time;
>>> +		__le16 date;
>>> +		u8 ctime_cs;
>>> +
>>> +		if (now == NULL) {
>>> +			now = &ts;
>>> +			ts = current_time(inode);
>>> +		}
>>> +
>>> +		if (flags & S_ATIME) {
>>> +			fat_time_unix2fat(sbi, now, &time, &date, NULL);
>>> +			fat_time_fat2unix(sbi, &inode->i_atime, 0, date, 0);
>>> +		}
>>> +		if (flags & S_MTIME) {
>>> +			fat_time_unix2fat(sbi, now, &time, &date, NULL);
>>> +			fat_time_fat2unix(sbi, &inode->i_mtime, time, date, 0);
>>> +		}
>>> +		if (flags & S_CTIME) {
>>> +			fat_time_unix2fat(sbi, now, &time, &date,
>>> +				sbi->options.isvfat ? &ctime_cs :  NULL);
>>> +			fat_time_fat2unix(sbi, &inode->i_ctime, time, date,
>>> +				sbi->options.isvfat ? ctime_cs : 0);
>>> +		}
>> 
>> Can't we use timespec_trunc() here (have to check limit of timestamp
>> though)? Convert twice is inefficient.
>
> Completely agreed on the inefficiency...
>
> timespec_trunc() doesn't work well for fat, mostly because it will only
> truncate down to 1 second, so some additional logic would be needed for
> 2-second mtime or 24-hour atime.  It is also called from elsewhere in
> the fs code using the single time granularity available in the
> super_block, so that time granularity is used for all of i_[acm]time
>
> As far as efficiency, I will look into extracting just the truncate
> behavior of fat_time_unix2fat to use that.  The patch was aiming for reuse.
>
> Is the result of the fat_time_unix2fat truncate of 2-second mtime in
> 'struct tm' equivalent to (i_mtime & ~0x1) ?  If we can bypass the need
> to convert to 'struct tm' for the truncate, and then back, that's
> clearly better.

Ah, right. Can we make fat_timespec_trunc()? I think we can truncate
time what we want without limitation. AFAIK, fat_update_time() and
setattr_copy() is enough to add to fat_timespec_trunc().

And ->s_time_gran doesn't work to skip timespec_equal() check as you
said. So, fat_update_time() may be better to have timespec_equal() check
after fat_timespec_trunc().

>>> +	}
>>> +	if ((flags & (S_ATIME | S_CTIME | S_MTIME)) &&
>>> +	    !(inode->i_sb->s_flags & SB_LAZYTIME))
>>> +		iflags |= I_DIRTY_SYNC;
>>> +
>>> +	__mark_inode_dirty(inode, iflags);
>> 
>> We should make this i_[acm]time update to function, and use everywhere,
>> or such. So we can skip needless mark_inode_dirty() on metadata update.
>
> I can remove; there's at least one location in current code where
> metadata is not getting updated to disk without.  I'm still working to
> locate it.

We need __mark_inode_dirty() for ->update_time() callback though. I
meant, __mark_inode_dirty() should not be required for direct call of
fat_update_time() in patch that replaced i_xxxx = current_time();

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

      reply	other threads:[~2018-04-09 22:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-04  2:37 [PATCH V2 1/2] fat: implement fat_update_time for inode timestamps Frank Sorenson
2018-04-08  0:11 ` OGAWA Hirofumi
2018-04-09 16:27   ` Frank Sorenson
2018-04-09 22:25     ` OGAWA Hirofumi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87efjouiet.fsf@mail.parknet.co.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sorenson@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.