From owner-freebsd-current Sun Aug 22 10:26:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3AC5815540 for ; Sun, 22 Aug 1999 10:26:50 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA80221; Sun, 22 Aug 1999 10:24:16 -0700 (PDT) (envelope-from dillon) Date: Sun, 22 Aug 1999 10:24:16 -0700 (PDT) From: Matthew Dillon Message-Id: <199908221724.KAA80221@apollo.backplane.com> To: Maxim Sobolev Cc: current@FreeBSD.ORG Subject: Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem References: <37BFD2E4.370EA4A4@altavista.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I do not know if it is bug or feature, but it seems that sync(8) command :doesn't really flushing write buffers for softdep enabled f/s. IMHO this :behavior is not very friendly for the notebooks and ATX owners because :before putting computer into sleep mode OS preferably should try to :write as many as possible unflushed buffers to disk (see :/etc/rc.suspend). Following is simple showcase for above described :(mis)behaviour: It's a bug, one that I've brought up with Kirk. The problem is that the structures used internally by softupdates are not condusive to doing a hard-sync. This creates other problems, too -- when the kernel bawrite()'s a buffer softupdates may write something different to the disk and then re-dirty the buffer, so performance will drop if the buffer cache becomes saturated and you are doing a lot of ops that require softupdates-related buffer rewriting. Kirk has been looking for a solution. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message