From owner-freebsd-stable@FreeBSD.ORG Sat Apr 12 09:23:20 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E571737B401; Sat, 12 Apr 2003 09:23:20 -0700 (PDT) Received: from tel.fer.hr (zg05-232.dialin.iskon.hr [213.191.138.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53EF743FBF; Sat, 12 Apr 2003 09:23:19 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr ([192.168.202.105]) by tel.fer.hr (8.12.6/8.12.6) with ESMTP id h3CGLHaA000350; Sat, 12 Apr 2003 18:21:32 +0200 (CEST) (envelope-from zec@tel.fer.hr) Message-ID: <3E983D60.CFCB950A@tel.fer.hr> Date: Sat, 12 Apr 2003 18:22:56 +0200 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein References: <3E976EBD.C3E66EF8@tel.fer.hr> <20030412033307.GR30960@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-fs@freebsd.org cc: mckusick@McKusick.COM cc: freebsd-stable@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 16:23:21 -0000 Alfred Perlstein wrote: > * Marko Zec [030411 19:01] wrote: > > > > When enabled, the extended delaying policy introduces some additional > > changes: > > > > - fsync() no longer flushes the buffers to disk, but returns immediately > > instead; > > This is really the only bad thing I can see here, what about introducing > a slight delay and seeing if one can coalesce the writes? Is this > part really needed? Making fsync() not work is a good way to make > any sort of userland based transactional system break badly. The motivation for hacking fsync() was in preventing some common tasks from spinning up the disk. One example is the vi editor, which if I'm not mistaking calls fsync() on the same moment as one starts modifying the file, not to mention on explicit :w. If the disk would start spinning every now and than, the whole patch would than become pointless... Nevertheless, the fact that the modified fsync() just returns without doing anything useful doesn't mean the data will be lost - it will simply be delayed until the next coalesced updating occurs. Marko