From owner-freebsd-fs@FreeBSD.ORG Fri Mar 12 13:05:48 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90F7F16A4CE for ; Fri, 12 Mar 2004 13:05:48 -0800 (PST) Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu [128.213.1.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45EF443D31 for ; Fri, 12 Mar 2004 13:05:48 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from 128.213.50.12 (kiki.cs.rpi.edu [128.213.50.12]) i2CL5ln7076235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Mar 2004 16:05:47 -0500 (EST) From: "David E. Cross" To: freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary="=-fhhiQwkC/bVpGhwSB2AH" Message-Id: <1079125546.4345.84.camel@kiki.cs.rpi.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 12 Mar 2004 16:05:47 -0500 X-Scanned-By: MIMEDefang 2.37 Subject: [Fwd: Re: JUFS update, and questions.] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2004 21:05:48 -0000 --=-fhhiQwkC/bVpGhwSB2AH Content-Type: text/plain Content-Transfer-Encoding: 7bit --=-fhhiQwkC/bVpGhwSB2AH Content-Disposition: inline Content-Description: Forwarded message - Re: JUFS update, and questions. Content-Type: message/rfc822 Subject: Re: JUFS update, and questions. From: "David E. Cross" To: Max Khon In-Reply-To: <20040311061906.GA35178@iclub.nsu.ru> References: <1078964168.4345.27.camel@kiki.cs.rpi.edu> <20040311061906.GA35178@iclub.nsu.ru> Content-Type: text/plain Message-Id: <1079122939.4345.41.camel@kiki.cs.rpi.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 12 Mar 2004 15:22:19 -0500 Content-Transfer-Encoding: 7bit On Thu, 2004-03-11 at 01:19, Max Khon wrote: > Do you plan to implement data journalling? > > Regards, Not in the initial release. There is an opcode reserved, however there are a few issues that I am not able to address currently. 1) The journal is based on disk blocks (filesystem blocks to be specific), a write of a complete block of data won't fit in a FSblocksize. It should be trivial to relax this limitation. The other is the case of a write(v)(2) that is larger than the journal itself. In this case the only thing I can think of is to force flush the entire journal and make the entire operation sync at that point.... but... this is something to be handled after the initial release (though perhaps relaxing the per-block restriction would be a good thing to do "now"). Note that data journaling is not the panacea to data integrity. The system does not know what writes need to be grouped together (consider a database operation that writes the new record and then the index, those are 2 separate writes, there is no way for the kernel to know they need to be completed together atomically; the database application needs its own method of transactions to guarantee integrity, the only thing the journal could provide is the notion that writes occur in-order). -- David E. Cross --=-fhhiQwkC/bVpGhwSB2AH--