From: Ritesh Kumar <digitalove@gmail.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: John Stoffel <john@stoffel.org>,
Jamie Lokier <jamie@shareable.org>,
"Artem B. Bityuckiy" <dedekind@oktetlabs.ru>,
Ville Herva <v@iki.fi>,
Linux Filesystem Development <linux-fsdevel@vger.kernel.org>
Subject: Re: filesystem transactions API
Date: Tue, 26 Apr 2005 11:29:57 -0400 [thread overview]
Message-ID: <fc67f8b705042608296e4abcb8@mail.gmail.com> (raw)
In-Reply-To: <1114528782.13568.8.camel@lade.trondhjem.org>
On 4/26/05, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> ty den 26.04.2005 Klokka 11:01 (-0400) skreiv John Stoffel:
> > >>>>> "Jamie" == Jamie Lokier <jamie@shareable.org> 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 <trond.myklebust@fys.uio.no>
>
> -
> 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/
next prev parent reply other threads:[~2005-04-26 15:30 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-24 20:08 [PATCH] private mounts Miklos Szeredi
2005-04-24 20:13 ` Al Viro
2005-04-24 20:45 ` Miklos Szeredi
2005-04-24 20:18 ` Christoph Hellwig
2005-04-24 20:50 ` Miklos Szeredi
2005-04-24 20:54 ` Al Viro
2005-04-24 20:59 ` Miklos Szeredi
2005-04-24 21:06 ` Al Viro
2005-04-24 21:15 ` Miklos Szeredi
2005-04-24 21:19 ` Al Viro
2005-04-24 21:29 ` Miklos Szeredi
2005-04-24 21:39 ` Jamie Lokier
2005-04-25 7:10 ` Jan Hudec
2005-04-25 9:58 ` Miklos Szeredi
2005-04-25 11:45 ` Jan Hudec
2005-04-30 8:35 ` Christoph Hellwig
2005-04-30 9:25 ` Miklos Szeredi
2005-04-30 9:42 ` Jamie Lokier
2005-04-30 10:14 ` Miklos Szeredi
2005-04-30 14:36 ` Jamie Lokier
2005-04-30 15:59 ` Miklos Szeredi
2005-04-30 16:42 ` Jamie Lokier
2005-04-30 17:07 ` Miklos Szeredi
2005-04-30 18:20 ` Olivier Galibert
2005-04-30 23:58 ` Jamie Lokier
2005-05-01 2:39 ` Ram
2005-04-30 23:54 ` Jamie Lokier
2005-05-01 5:56 ` Miklos Szeredi
2005-05-01 6:39 ` Miklos Szeredi
2005-05-01 15:41 ` Eric Van Hensbergen
2005-05-11 9:00 ` Christoph Hellwig
2005-05-11 10:42 ` Miklos Szeredi
2005-04-24 21:43 ` Jamie Lokier
2005-04-24 22:06 ` maciek
2005-04-25 7:14 ` Jan Hudec
2005-04-27 9:14 ` Helge Hafting
2005-04-25 9:48 ` Olivier Galibert
2005-04-25 16:37 ` Tim Hockin
2005-04-30 8:37 ` Christoph Hellwig
2005-04-25 21:09 ` Bryan Henderson
2005-04-26 13:46 ` filesystem transactions API Ville Herva
2005-04-26 14:14 ` Jamie Lokier
2005-04-26 14:22 ` Artem B. Bityuckiy
2005-04-26 14:32 ` Jamie Lokier
2005-04-26 14:46 ` Artem B. Bityuckiy
2005-04-26 15:19 ` Jamie Lokier
2005-04-26 15:01 ` John Stoffel
2005-04-26 15:12 ` Lars Marowsky-Bree
2005-04-26 15:12 ` Lars Marowsky-Bree
2005-04-26 15:19 ` Trond Myklebust
2005-04-26 15:29 ` Ritesh Kumar [this message]
2005-04-26 15:50 ` Jamie Lokier
2005-04-26 16:44 ` Trond Myklebust
2005-04-26 22:44 ` Bryan Henderson
2005-04-26 15:47 ` Jamie Lokier
2005-04-26 15:51 ` Artem B. Bityuckiy
2005-04-26 15:56 ` Jamie Lokier
2005-04-26 16:01 ` Artem B. Bityuckiy
2005-04-27 9:14 ` Jan Hudec
2005-04-27 10:58 ` Bernd Eckenfels
2005-04-26 15:24 ` Jamie Lokier
2005-04-26 17:22 ` Diego Calleja
2005-04-26 17:22 ` Diego Calleja
2005-04-26 17:38 ` Jamie Lokier
2005-04-27 9:34 ` Jan Hudec
2005-04-27 13:43 ` Ville Herva
2005-04-27 15:17 ` Jamie Lokier
2005-04-27 16:58 ` Bernd Eckenfels
2005-04-26 15:40 ` Charles P. Wright
2005-04-26 16:07 ` Artem B. Bityuckiy
2005-04-26 17:22 ` Charles P. Wright
2005-04-27 9:37 ` Lars Marowsky-Bree
2005-04-27 9:37 ` Lars Marowsky-Bree
2005-04-27 13:36 ` Andi Kleen
2005-04-26 14:25 ` Trond Myklebust
2005-04-26 16:22 ` Erik Hensema
2005-04-24 21:38 ` [PATCH] private mounts Jamie Lokier
2005-04-24 22:20 ` Ram
2005-04-24 22:22 ` Jamie Lokier
2005-04-25 6:00 ` Miklos Szeredi
2005-04-25 6:41 ` Ram
2005-04-25 9:55 ` Miklos Szeredi
2005-04-25 7:22 ` Jan Hudec
2005-04-25 10:08 ` Miklos Szeredi
2005-04-25 15:20 ` Pavel Machek
2005-04-25 19:07 ` Jamie Lokier
2005-04-26 9:29 ` Pavel Machek
2005-04-26 14:07 ` Jamie Lokier
2005-04-28 13:28 ` Eric Van Hensbergen
2005-04-28 19:22 ` Jamie Lokier
2005-04-28 13:47 ` Eric Van Hensbergen
2005-04-28 19:20 ` Jamie Lokier
2005-04-28 19:39 ` Ram
2005-04-28 22:08 ` Jamie Lokier
2005-04-29 7:57 ` Ram
2005-04-29 14:13 ` Miklos Szeredi
2005-04-29 14:42 ` Jamie Lokier
2005-04-29 14:50 ` Question about current->namespace and check_mnt() Jamie Lokier
2005-04-30 8:33 ` [PATCH] private mounts Christoph Hellwig
2005-04-30 16:47 ` Ram
2005-04-24 21:06 ` Christoph Hellwig
2005-04-24 21:12 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc67f8b705042608296e4abcb8@mail.gmail.com \
--to=digitalove@gmail.com \
--cc=dedekind@oktetlabs.ru \
--cc=jamie@shareable.org \
--cc=john@stoffel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ritesh@cs.unc.edu \
--cc=trond.myklebust@fys.uio.no \
--cc=v@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.