Date: 12 Mar 2004 16:05:47 -0500 From: "David E. Cross" <crossd@cs.rpi.edu> To: freebsd-fs@freebsd.org Subject: [Fwd: Re: JUFS update, and questions.] Message-ID: <1079125546.4345.84.camel@kiki.cs.rpi.edu>
next in thread | raw e-mail | index | archive | help
--=-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" <crossd@cs.rpi.edu> To: Max Khon <fjoe@iclub.nsu.ru> In-Reply-To: <20040311061906.GA35178@iclub.nsu.ru> References: <Pine.BSF.4.21.0403101546090.15852-100000@InterJet.elischer.org> <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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1079125546.4345.84.camel>