Messages in this thread | | | Date | Thu, 2 Oct 2008 22:00:40 -0700 | From | Arjan van de Ven <> | Subject | Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority |
| |
On Thu, 2 Oct 2008 21:50:26 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > I also notice it's part of "file_update_time". Do we really need to > > go all the way down to this level of synchronicity for that? > > Well, we've tossed that around many times but never implemented it. > Once you get into the details it gets a bit nasty. Need to keep the > dirtiness state in the VFS (or fs) inode, and going backwards from a > plain old buffer_head at commit time isn't possible. We usually > tempfixed the problem by adding increasingly fancy ways of not doing > the atime update at all.
given that this is the write path, I was assuming this was mtime rather than atime; doesn't change your answer though. > > Of course, fixing this running-vs-committing contention point would > fix a lot more things than just atime updates.
yes clearly. It's waaay above my paygrade to hack on though; JBD is one of those places in the kernel that scare me for doing fundamental changes ;-(
> > > (I also randomly wonder if we, in the write path, dirty the inode > > twice, once for size once for item, and if we then also reserve two > > slots in the journal for that..... > > That shouldn't be the case - once we have write access to the buffer > it remains freely modifiable for the rest of the transaction period. > I think.
I hope you're right otherwise we'd always hit this; once for the size change, then block for the mtime. That would thoroughly suck; so much so that you just must be right.
-- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
| |