linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  reply	other threads:[~2008-12-22 19:15 UTC|newest]

Thread overview: 49+ 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: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: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: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 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).