Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 12 Feb 2002 23:01:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 12 Feb 2002 23:01:30 -0500 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:45071 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id ; Tue, 12 Feb 2002 23:01:13 -0500 Message-ID: <3C69E506.5DBE50A@mandrakesoft.com> Date: Tue, 12 Feb 2002 23:01:10 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Davidsen CC: Linux Kernel Mailing List Subject: Re: [patch] sys_sync livelock fix In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Bill Davidsen wrote: > > Alan and/or Linus: > > Am I misreading this or is the Linux implementation of sync() based on > making the shutdown scripts pause until disk i/o is done? Because I don't > think commercial unices work that way, I think they work as SuS > specifies. More reason to rethink this in 2.4 as well as 2.5 and get the > possible live lock out of the kernel. I don't think SuSv2 can be any more clear than: > The writing, although scheduled, is not necessarily complete > upon return from sync(). Quoting from http://www.opengroup.org/onlinepubs/007908799/xsh/sync.html As I mentioned in the other message, IMHO we need some way to introduce a global system I/O barrier, and then wait for all I/O scheduled before that barrier to complete. My suggestion for naming was the "checkpoint" system call. Jeff -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/