From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ritesh Kumar Subject: Re: filesystem transactions API Date: Tue, 26 Apr 2005 11:29:57 -0400 Message-ID: References: <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <20050426134629.GU16169@viasys.com> <20050426141426.GC10833@mail.shareable.org> <426E4EBD.6070104@oktetlabs.ru> <20050426143247.GF10833@mail.shareable.org> <17006.22498.394169.98413@smtp.charter.net> <1114528782.13568.8.camel@lade.trondhjem.org> Reply-To: ritesh@cs.unc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: John Stoffel , Jamie Lokier , "Artem B. Bityuckiy" , Ville Herva , Linux Filesystem Development Return-path: Received: from wproxy.gmail.com ([64.233.184.199]:16445 "EHLO wproxy.gmail.com") by vger.kernel.org with ESMTP id S261608AbVDZPaB convert rfc822-to-8bit (ORCPT ); Tue, 26 Apr 2005 11:30:01 -0400 Received: by wproxy.gmail.com with SMTP id 68so1950433wri for ; Tue, 26 Apr 2005 08:29:58 -0700 (PDT) To: Trond Myklebust In-Reply-To: <1114528782.13568.8.camel@lade.trondhjem.org> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 4/26/05, Trond Myklebust wrote: > ty den 26.04.2005 Klokka 11:01 (-0400) skreiv John Stoffel: > > >>>>> "Jamie" == Jamie Lokier writes: > > > > Jamie> No. A transaction means that _all_ processes will see the > > Jamie> whole transaction or not. > > > > This is really hard. How do you handle the case where process X > > starts a transaction modifies files a, b & c, but process Y has file b > > open for writing, and never lets it go? Or the file gets unlinked? > > That is why implementing it as a form of lock makes sense. > > > Jamie> For example, you can use transactions for distro package > > Jamie> management: a whole update of a package would be a single > > Jamie> transaction, so that at no time does any program see an > > Jamie> inconsistent set of files. See why _every_ process in the > > Jamie> system must have the same view? > > > > What about programs that are already open and running? > > > > It might be doable in some sense, but I can see that details are > > really hard to get right. Esp without breaking existing Unix > > semantics. > > Wrong. > > Cheers, > Trond > -- > Trond Myklebust > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > I was wondering if it was also important to commit the changes to persistent storage once the transaction has been completed or is it just important that all processes see the changes atomically. I mean, is it also important that before any of the processes see the result of the transaction, or before the 'transacting' process knows the transaction is complete, the changes must be flushed to persistent storage? That would be all the more reason to implement it in kernel space... Ritesh P.S. Sorry... I missed the reply_all button for the first mail. -- http://www.cs.unc.edu/~ritesh/