linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jorg@ml1.net
To: "OGAWA Hirofumi" <hirofumi@mail.parknet.co.jp>,
	"Jorg Schummer" <ext-jorg.2.schummer@nokia.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH take 3][RFC] fat: Save FAT root directory timestamps to volume label
Date: Fri, 18 Sep 2009 15:14:10 +0300	[thread overview]
Message-ID: <1253276050.9376.1335476075@webmail.messagingengine.com> (raw)
In-Reply-To: <878wgcsd1p.fsf@devron.myhome.or.jp>

Hello and thanks for your comments!

On Fri, 18 Sep 2009 20:33 +0900, "OGAWA Hirofumi"
<hirofumi@mail.parknet.co.jp> wrote:
> Jorg Schummer <ext-jorg.2.schummer@nokia.com> writes:
> 
> > Standard FAT implementations cannot store any of the FAT root directory's
> > timestamps. This commit adds the mount option 'rootts', which allows saving
> > the FAT root directory timestamps as the timestamps of the FAT volume label
> > directory entry. At least Mac OS X is known to support the same mechanism
> > and interoperate with this commit.
> >
> > When mounting, the following values can be specified for the 'rootts' mount
> > option:
> >
...
> >
> >   "rootts=save"     tries to load and save the root directory's timestamps.
> >                     The mtime and atime are corrected based on root
> >                     directory entries' ctime. If the root directory was
> >                     accessed but no volume label entry exists, the label
> >                     "NO NAME" is created.
> 
> Um..., I'm still not sure though. rootts=save may not be needed for
> this, because it seems a bit complex, and it can do on userland...

It's true, that is quite of a hack after all. I just thought I'll try to
add the non-plus-ultra-feature on top of what Mac OS can do already.

But you're right, I'll get rid of the label creation. (And I think I
should get rid of the time stamp correction as well. If there is no
timestamp to be loaded, then 1970/1/1 should suffice. In case anyone
thinks that the timestamp 'correction' is anyhow useful, let me know...)

> 
> And some quick review of implement..
> 
> > +	if (inode->i_ino == MSDOS_ROOT_INO) {
> 
> In this path, we don't have inode->i_mutex, so to look directry up is
> wrong. I think adding label may move to userland.
> 
> I guess we should do all of preparation in fill_super().

True. This code is only needed for the time stamp creation, so it'll go
in any case.

> 
> > +			remove_inode_hash(inode);
> > +			fat_attach(inode, i_pos);
> > +			insert_inode_hash(inode);
> > +			brelse(bh);
> 
> Root inode should never change the position, so this shouldn't be
> needed.

Like above, this will be removed.

If 'preserve' (i.e. saving and loading the timestamp only IF a label is
present) is the default, I'll remove the 'rootts=preserve' option.
However, should there still be an option to switch this feature off
completely ('rootts=ignore')?

Thanks very much for your comments, the next version will come soon!

Jörg

  reply	other threads:[~2009-09-18 12:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1248274841-3586-1-git-send-email-ext-jorg.2.schummer@nokia.com>
2009-07-24  9:43 ` [PATCH take 2][RFC] fat: Save FAT root directory timestamps to volume label Jorg Schummer
2009-07-25  5:48   ` OGAWA Hirofumi
2009-07-27 10:47     ` Jörg Schummer
2009-07-27 11:47       ` OGAWA Hirofumi
2009-07-27 13:03         ` Jörg Schummer
2009-07-27 14:56         ` Jörg Schummer
2009-07-27 15:10           ` OGAWA Hirofumi
2009-08-04  8:42         ` Jörg Schummer
2009-08-04 10:32           ` OGAWA Hirofumi
2009-09-08 14:28             ` [PATCH take 3][RFC] " Jörg Schummer
2009-09-08 14:34               ` Jorg Schummer
2009-09-08 15:39                 ` Jamie Lokier
2009-09-09  7:47                   ` Jörg Schummer
2009-09-15 11:03                 ` Jörg Schummer
2009-09-18 11:33                 ` OGAWA Hirofumi
2009-09-18 12:14                   ` jorg [this message]
2009-09-19 14:46                     ` OGAWA Hirofumi

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=1253276050.9376.1335476075@webmail.messagingengine.com \
    --to=jorg@ml1.net \
    --cc=ext-jorg.2.schummer@nokia.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).