From: Bart Samwel <bart@samwel.tk>
To: Andrew Morton <akpm@osdl.org>
Cc: Sam Vilain <sam@vilain.net>,
hirofumi@mail.parknet.co.jp, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Write the inode itself in block_fsync()
Date: Fri, 10 Mar 2006 15:12:12 +0100 [thread overview]
Message-ID: <4411893C.6020008@samwel.tk> (raw)
In-Reply-To: <20060309201053.682868db.akpm@osdl.org>
Andrew Morton wrote:
> Sam Vilain <sam@vilain.net> wrote:
>> OGAWA Hirofumi wrote:
>>
>> >For block device's inode, we don't write a inode's meta data
>> >itself. But, I think we should write inode's meta data for fsync().
>>
>> Ouch... won't that halve performance of database transaction logs?
>
> Yes, it could well cause a lot more seeking to do atime and/or mtime
> writes. Which aren't terribly important, really.
>
> Unless I'm missing something, I suspect we'd be better off without this,
> even though it's a correctness fix :(
Maybe atime/mtime aren't important, but I would be unhappy if a file
size change wasn't written to disk on fsync.
Anyway, shouldn't databases be using a combination of fixed-size files
and fdatasync? fsync doesn't perform well by definition, and I guess the
only reason databases still use it is because the kernel failed to
implement the sucky part of the behaviour.
A complex but perhaps viable suggestion: as atime/mtime are stored on
disk in second granularity (on ext3 at least, don't know about other
fss), wouldn't it somehow be possible to only regard atime/mtime changes
as real changes when i_(a|c)time.tv_sec changes? This would enable fsync
to write the inode once every second instead of on every fsync. The
performance drop would be much less dramatic than writing the inode on
every fsync, and it would at least yield correct behaviour.
Cheers,
Bart
next prev parent reply other threads:[~2006-03-10 14:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-09 16:22 [PATCH] Write the inode itself in block_fsync() OGAWA Hirofumi
2006-03-10 1:05 ` Sam Vilain
2006-03-10 4:10 ` Andrew Morton
2006-03-10 14:12 ` Bart Samwel [this message]
2006-03-10 15:18 ` OGAWA Hirofumi
2006-03-10 17:32 ` Bart Samwel
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=4411893C.6020008@samwel.tk \
--to=bart@samwel.tk \
--cc=akpm@osdl.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@vilain.net \
/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