linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Lord <lord@sgi.com>
To: Chris Mason <mason@suse.com>
Cc: Steve Lord <lord@sgi.com>, Jeremy Hansen <jeremy@xxedgexx.com>,
	linux-kernel@vger.kernel.org
Subject: Re: scsi vs ide performance on fsync's
Date: Fri, 02 Mar 2001 13:25:25 -0600	[thread overview]
Message-ID: <200103021925.f22JPPU02085@jen.americas.sgi.com> (raw)
In-Reply-To: Message from Chris Mason <mason@suse.com>  of "Fri, 02 Mar 2001 14:17:44 EST." <383290000.983560664@tiny>

> 
> 
> On Friday, March 02, 2001 12:39:01 PM -0600 Steve Lord <lord@sgi.com> wrote:
> 
> [ file_fsync syncs all dirty buffers on the FS ]
> > 
> > So it looks like fsync is going to cost more for bigger devices. Given the
> > O_SYNC changes Stephen Tweedie did, couldnt fsync look more like this:
> > 
> >	 down(&inode->i_sem);
> >         filemap_fdatasync(ip->i_mapping);
> >         fsync_inode_buffers(ip);
> >         filemap_fdatawait(ip->i_mapping);
> >	 up(&inode->i_sem);
> > 
> 
> reiserfs might need to trigger a commit on fsync, so the fs specific fsync
> op needs to be called.  But, you should not need to call file_fsync in the
> XFS fsync call (check out ext2's)


Right, this was just a generic example, the fsync_inode_buffers would be in
the filesystem specific fsync callout - this was more of a logical
example of what ext2 could do. XFS does completely different stuff in there
anyway. 

> 
> For why ide is beating scsi in this benchmark...make sure tagged queueing
> is on (or increase the queue length?).  For the xlog.c test posted, I would
> expect scsi to get faster than ide as the size of the write increases.

I think the issue is the call being used now is going to get slower the
larger the device is, just from the point of view of how many buffers it
has to scan.

> 
> -chris

Steve



  reply	other threads:[~2001-03-02 19:26 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-02 17:42 scsi vs ide performance on fsync's Jeremy Hansen
2001-03-02 18:39 ` Steve Lord
2001-03-02 19:17   ` Chris Mason
2001-03-02 19:25     ` Steve Lord [this message]
2001-03-02 19:27       ` Jeremy Hansen
2001-03-02 19:38       ` Chris Mason
2001-03-02 19:41         ` Steve Lord
2001-03-05 13:23         ` Andi Kleen
2001-03-02 19:25     ` Andre Hedrick
2001-03-03  1:55     ` Dan Hollis
2001-03-02 20:56 ` Linus Torvalds
2001-03-06  2:13   ` Jeremy Hansen
2001-03-06  2:25     ` Linus Torvalds
2001-03-06  3:30     ` Jonathan Morton
2001-03-06  4:05       ` Linus Torvalds
2001-03-06  7:03       ` Andre Hedrick
2001-03-06  8:24       ` Jonathan Morton
2001-03-06 12:22         ` Rik van Riel
2001-03-06 14:08         ` Jonathan Morton
2001-03-07 16:50           ` Pavel Machek
2001-03-06 19:41         ` Andre Hedrick
2001-03-07  5:25         ` Jonathan Morton
2001-03-07  6:58           ` Andre Hedrick
2001-03-09 11:39       ` Jonathan Morton
     [not found] <Pine.LNX.4.33L2.0103021033190.6176-200000@srv2.ecropolis.com>
     [not found] ` <054201c0a33d$55ee5870$e1de11cc@csihq.com>
2001-03-04 20:10   ` Douglas Gilbert
2001-03-04 21:28     ` Ishikawa
2001-03-06  0:11     ` Douglas Gilbert
2001-03-06  5:27 Douglas Gilbert
2001-03-06  5:45 ` Linus Torvalds
2001-03-06  7:12   ` Andre Hedrick
2001-03-06 12:09     ` Alan Cox
2001-03-06 18:44       ` Linus Torvalds
2001-03-07 13:48         ` Stephen C. Tweedie
2001-03-07 14:13           ` Jens Axboe
2001-03-12 18:50           ` Andre Hedrick
2001-03-06 13:50     ` Mike Black
2001-03-06 16:02       ` Jeremy Hansen
2001-03-07 18:27         ` Jeremy Hansen
2001-03-07 18:36           ` Linus Torvalds
2001-03-08 11:06             ` Stephen C. Tweedie
2001-03-06 16:57       ` Jonathan Morton
2001-03-06  6:43 ` Jonathan Morton
2001-03-06 13:03   ` dean gaudet
2001-03-06 13:15     ` dean gaudet
2001-03-06 13:45     ` Jonathan Morton
2001-03-06 17:14 David Balazic
2001-03-06 17:46 ` Gregory Maxwell
2001-03-06 18:23 ` Jonathan Morton
2001-03-06 23:27   ` Mark Hahn
2001-03-06 19:42 David Balazic
2001-03-06 20:37 ` Jens Axboe
2001-03-07 13:51   ` Stephen C. Tweedie
2001-03-07 14:12     ` Jens Axboe
2001-03-07 15:05       ` Stephen C. Tweedie
2001-03-07 18:51         ` Jens Axboe
2001-03-07 19:10           ` Stephen C. Tweedie
2001-03-07 20:15             ` Jens Axboe
2001-03-07 20:56               ` Stephen C. Tweedie
2001-03-07 20:59                 ` Jens Axboe
2001-03-08 15:45                 ` Chris Mason
2001-03-07 12:47 David Balazic
     [not found] <1epyyz1.etswlv1kmicnqM%smurf@noris.de>
2001-03-09  6:59 ` Matthias Urlichs
2001-03-09 11:51   ` Jens Axboe
2001-03-09 14:26     ` Matthias Urlichs

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=200103021925.f22JPPU02085@jen.americas.sgi.com \
    --to=lord@sgi.com \
    --cc=jeremy@xxedgexx.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mason@suse.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).