From owner-freebsd-current Sun Aug 22 11:42:43 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 196981559E for ; Sun, 22 Aug 1999 11:42:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA14642; Sun, 22 Aug 1999 11:39:24 -0700 (PDT) (envelope-from dillon) Date: Sun, 22 Aug 1999 11:39:24 -0700 (PDT) From: Matthew Dillon Message-Id: <199908221839.LAA14642@apollo.backplane.com> To: Poul-Henning Kamp Cc: Maxim Sobolev , current@FreeBSD.ORG Subject: Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem References: <4301.935346213@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :But the buffer to buffer dependencies are already recorded in the :sequence on the "sync-wheel" which the syncer daemon runs through, :isn't it ? : :-- :Poul-Henning Kamp FreeBSD coreteam member :phk@FreeBSD.ORG "Real hackers run -current on their laptop." Only very roughly. The syncer wheel tries to order whole vnodes amoungst whole vnodes, making the distinction between vnode types VDIR, VBLK, and VREG. This helps reduce the amount of rewriting that softupdates must accomplish, but it only orders buffer dependancies in a very rough fashion. Within the dirtyblkhd list in each vnode, which lists the dirty buffers, we also do a rough ordering. If you look at reassignbuf() in vfs_subr.c you will see how this works. We attempt to sort blocks in the dirtyblkhd list and we place meta data (negative block numbers) at the end of the list instead of at the head. The idea here is to write out data blocks before writing out the meta-data. If the meta-data were to be written out first softupdates would step in and rearrange the meta-data being written to the physical media to take into account the fact that the data blocks have not yet been written. In otherwords, the metadata buffer would remain dirty. But both of these ordering cases are only rough approximations designed h to reduce the amount of work that softupdates must accomplish. Softupdates understands the concept of filesystem dependancies such as, for example, a directory entry depending on an inode. but softupdates does *NOT* directly understand 'macro' buffer<->buffer dependancies so there is no 'chain of buffers' for the flushing code to follow to get things in the right order. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message