Re: Improvements to fsck performance in -current ...?

From: Don Lewis (truckman_at_FreeBSD.org)
Date: 10/02/03

  • Next message: Martin: "Re: IDE DVD playback on 5.1-CURRENT" 
    Date: Thu, 2 Oct 2003 13:51:06 -0700 (PDT)
To: tlambert2@mindspring.com

    On 2 Oct, Terry Lambert wrote:
    > Jens Rehsack wrote:
    >> Kevin Oberman wrote:
    >> > Current has two major changes re speeding up fsck.
    >> >
    >> > The most significant is the background operation of fsck on file
    >> > system with soft updates enabled. Because of the way softupdates
    >> > works, you are assured of metadata consistency on reboot, so the file
    >> > systems can be mounted and used immediately with fsck started up in
    >> > the background about a minute after the system comes up.
    >>
    >> Be careful what you promise :-)
    >> Most new disks have an own disk cache and some of them have a
    >> write cache enabled. In case of a hardware failure (or power
    >> failure) this data may get lost and the disk's metadata isn't
    >> consistent. It's only when no write cache below the system
    >> is active.
    >
    > Actually, write caching is not so much the problem, as the disk
    > reporting that the write has completed before the contents of
    > the transaction saved in the write cache have actually been
    > committed to stable storage.
    >
    > Unfortunately, IDE disks do not permit disconnected writes, due
    > to a bug in the original IDE implementation, which has been
    > carried forward for [insert no good reason here].
    >
    > Therefore IDE disks almost universally lie to the driver any
    > time write caching is enabled on an IDE drive.
    >
    > In most cases, if you use SCSI, the problem will go away.

    Nope, they "lie" as well unless you turn of the WCE bit. Fortunately
    with tagged command queuing there is very little performance penalty for
    doing this in most cases. The main exception to this is when you run
    newfs which talks to the raw partition and only has one command
    outstanding at a time.

    Back in the days when our SCSI implementation would spam the console
    whenever it reduced the number of tagged openings because the drive
    indicated that its queue was full, I'd see the number of tagged openings
    stay at 63 if write caching was disabled, but the number would drop
    significantly under load (50%?) if write caching was enabled. I always
    suspected that the drive's cache was full of data for write commands
    that it had indicated to the host as being complete even though the data
    hadn't been written to stable storage.

    Unfortunately SCSI drives all seem to ship with the WCE bit set,
    probably for "benchmarking" reasons, so I always have to remember to
    turn this bit off whenever I install a new drive.
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Martin: "Re: IDE DVD playback on 5.1-CURRENT"

    Relevant Pages

    • Re: libata in 2.4.24?
      ... As a result SCSI disks are reliable for database ... if the OS driver has not issued a FLUSH CACHE ... I hope you mean the drives don't report completion until the data is on ...
      (Linux-Kernel)
    • Re: Improvements to fsck performance in -current ...?
      ... >> Current has two major changes re speeding up fsck. ... > write cache enabled. ... Unfortunately, IDE disks do not permit disconnected writes, due ...
      (freebsd-current)
    • Re: How to flush the disk write cache from userspace
      ... I think we really should have support for doing cache flushes ... drives in order to get proper data integrity guarantees - and disabling ... cache and thus we don't want to actually force the controller to flush ... I also think there's no point in disabling disks' write caches, ...
      (Linux-Kernel)
    • Re: How to flush the disk write cache from userspace
      ... I think we really should have support for doing cache flushes automatically on fsync, ... User space code should not have to worry about this problem, it's pretty silly that for example MySQL has to advise people to use hdparm -W 0 to disable the write cache on their IDE drives in order to get proper data integrity guarantees - and disabling the cache on IDE without command queueing really slaughters the performance, unnecessarily in this case. ... I also think there's no point in disabling disks' write caches, since it slows writes and decreases disks' lifetime, and because there's a better solution. ...
      (Linux-Kernel)
    • Re: Tips sought for optimizing 10.4.10s performance
      ... upgrade to disks with those speeds. ... Most desktop drives have been 7200 RPM, ... 7200 RPM disks have only had 2MB of cache. ... a CPU upgrade, or do I just get a new Mac. ...
      (comp.sys.mac.system)