xfs
[Top] [All Lists]

Re: [PATCH 5/5] xfs: log timestamp updates

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 5/5] xfs: log timestamp updates
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sun, 19 Feb 2012 16:43:54 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20120216073033.GE14132@dastard>
References: <20120207181037.745771452@xxxxxxxxxxxxxxxxxxxxxx> <20120207181155.671953164@xxxxxxxxxxxxxxxxxxxxxx> <20120216073033.GE14132@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Feb 16, 2012 at 06:30:33PM +1100, Dave Chinner wrote:
> Are you looking at adding specific superblock operation for updating
> timestamps on an inode? Or something else?

I talk to Josef Bacik about this and he was planning to add it for
btrfs.  If he doesn't do it I'll probably take care of it myself sooner
or later.

> As to fdatasync optimisations, we could just add a new (flags) field
> to the inode log item (i.e. separate to the format flags) that is
> set here if and only if the inode has not already had it's core
> logged and is in the CIL. If subsequent transactions that log the
> core clear that flag, then we have a flag that would only be set if
> timestamps have been logged by themselves.  That would give
> xfs_file_fsync some method of determining whether fdatasync
> should force the log or not....

That's what I'm looking into right now.  It's not quite as easy as
it sounds, e.g. because ilf_fields is part of the log format, so we
first need to add a new flags field that's still around with the
timestamp only flag after the inode has been logged and so on.  But I'm
making slow progress on it.

<Prev in Thread] Current Thread [Next in Thread>