From: Ric Wheeler <rwheeler@redhat.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Jan Kara <jack@suse.cz>, Arthur Jones <ajones@riverbed.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"sct@redhat.com" <sct@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ext3: wait on all pending commits in ext3_sync_fs
Date: Mon, 22 Dec 2008 14:15:10 -0500 [thread overview]
Message-ID: <494FE73E.5000802@redhat.com> (raw)
In-Reply-To: <494AFA16.2010004@redhat.com>
Eric Sandeen wrote:
> Jan Kara wrote:
>
>
>>> In looking at what we have today, I wonder if we can make things smarter
>>> so that we don't commit empty transactions in any case?
>>>
>> Probably it does not make sence to commit such transactions and we might
>> save some time in sync paths if we do so. So yes, I think skipping empty
>> transaction commit might be worthwhile and it shouldn't be hard to do
>> either. But I'd give it serious testing just in case some unexpectedly
>> relies on this behaviour - wouldn't this interfere e.g. with sync
>> transaction batching autotuning code? Untested patch below...
>> Honza
>>
>
>
> Cool, thanks! This's stop:
>
> # sync
>
> from spinning up disks under idle filesystems too, I think.
>
> I was looking at something similar but was still working out how many
> things to check before deciding if the transaction was in fact empty. :)
>
> -Eric
>
Without having dived into the patch in detail, one worry I would have is
that we still might care to spin up a drive for empty transactions in
order to invalidate the drive's write cache.
For example, if we have the following sequence:
(1) user app performs series of writes to file A
(2) pages dirtied from writes to A are destaged to the disk over time
(3) user app issues fsync(file A) to make sure that the data will
survive a power outage
At this point in time, would this change prevent us from spinning up the
drive and invalidating the disk write cache for that fsync() ?
Regards,
Ric
next prev parent reply other threads:[~2008-12-22 19:15 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-24 18:37 ext3: slow symlink corruption on umount Arthur Jones
2008-10-27 16:54 ` Arthur Jones
2008-10-29 19:54 ` Arthur Jones
2008-10-29 20:36 ` Eric Sandeen
2008-10-29 21:09 ` Theodore Tso
2008-10-30 13:38 ` Eric Sandeen
2008-10-30 13:38 ` Eric Sandeen
2008-10-30 13:55 ` Arthur Jones
2008-10-31 9:47 ` Nick Piggin
2008-10-30 17:40 ` Arthur Jones
2008-10-30 18:03 ` Eric Sandeen
2008-10-30 21:34 ` Arthur Jones
2008-10-31 17:24 ` Arthur Jones
2008-10-31 18:37 ` Eric Sandeen
2008-10-30 18:32 ` Arthur Jones
2008-11-03 18:44 ` [PATCH] ext3: wait on all pending commits in ext3_sync_fs Arthur Jones
2008-11-03 19:33 ` Andrew Morton
2008-11-03 20:14 ` Arthur Jones
2008-11-03 20:14 ` Arthur Jones
2008-11-03 20:37 ` Andrew Morton
2008-11-03 20:58 ` Arthur Jones
2008-11-03 21:13 ` Andrew Morton
2008-11-03 21:19 ` Theodore Tso
2008-11-03 21:27 ` Andrew Morton
2008-11-03 21:48 ` Theodore Tso
2008-11-03 22:01 ` Theodore Tso
2008-11-03 22:18 ` Arthur Jones
2008-11-03 22:27 ` Andrew Morton
2008-11-03 22:55 ` Theodore Tso
2008-11-03 23:01 ` Arthur Jones
2008-11-03 23:12 ` Theodore Tso
2008-11-04 16:26 ` Arthur Jones
2008-11-03 21:48 ` Arthur Jones
2008-11-03 22:47 ` Theodore Tso
2008-12-18 23:17 ` Jan Kara
2008-12-18 23:37 ` Eric Sandeen
2008-12-19 0:27 ` Jan Kara
2008-12-19 1:34 ` Eric Sandeen
2008-12-22 19:15 ` Ric Wheeler [this message]
2008-12-22 22:57 ` Andreas Dilger
2008-12-23 0:09 ` Ric Wheeler
2008-12-23 15:56 ` Eric Sandeen
2009-01-12 22:28 ` Jan Kara
2009-01-13 17:21 ` Eric Sandeen
2009-01-13 22:14 ` Eric Sandeen
2009-01-14 4:24 ` Theodore Tso
2009-01-14 17:26 ` Eric Sandeen
2009-01-14 17:26 ` Eric Sandeen
2009-01-14 17:27 ` Jan Kara
2009-01-14 17:27 ` Jan Kara
2009-01-29 18:27 ` Mike Snitzer
2009-01-29 20:05 ` Eric Sandeen
2008-11-03 19:59 ` Eric Sandeen
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=494FE73E.5000802@redhat.com \
--to=rwheeler@redhat.com \
--cc=ajones@riverbed.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=sct@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.