From: Ville Herva <vherva@vianova.fi>
To: Jan Hudec <bulb@ucw.cz>
Cc: Jamie Lokier <jamie@shareable.org>,
John Stoffel <john@stoffel.org>,
"Artem B. Bityuckiy" <dedekind@oktetlabs.ru>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: filesystem transactions API
Date: Wed, 27 Apr 2005 16:43:31 +0300 [thread overview]
Message-ID: <20050427134331.GT5470@viasys.com> (raw)
In-Reply-To: <20050427093412.GB1904@vagabond>
On Wed, Apr 27, 2005 at 11:34:12AM +0200, you [Jan Hudec] wrote:
> On Tue, Apr 26, 2005 at 16:24:34 +0100, Jamie Lokier wrote:
> > John Stoffel wrote:
> > > >>>>> "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?
> >
> > Then it starts to depend on what kind of transactions you want to
> > implement.
> >
> > You can say that a transaction isn't allowed when a process has one of
> > the files opened for writing. Or you can say a transaction is
> > equivalent to calling all of the I/O system calls at once. You can
> > also decide if you want the reads and directory lookups performed in
> > the transactions to become prerequisites for the transaction
> > completing (so it's aborted if another process writes to those file
> > regions or changes the directory structure in a way which breaks a
> > prerequisite), or if you want those to lock the things which are read
> > for the duration of the transaction, or even just ignore reads for
> > transaction purposes. Or, you can say that transactions are limited
> > to just directory structure, and not file contents (that's good enough
> > for package management), or you can say they're limited to just file
> > contents (that's good enough for databases and text file edits).
> >
> > Etc, etc, quite a lot of semantic choices.
>
> How do we specify which calls belong to a transaction? By some kind of
> extra file handle?
>
> I'd think having global per-process transaction is not the best way.
> So I think we should have some kind of transaction handle (probably in
> the file handle space) and a way to say that a syscall is done within
> a transaction. To avoid duplicating all syscalls, we could have
> set_active_transaction() operation.
That's more or less what NTFS does. See the example at
http://blogs.msdn.com/because_we_can/
-- v --
v@iki.fi
next prev parent reply other threads:[~2005-04-27 13:43 UTC|newest]
Thread overview: 95+ 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 ` Christoph Hellwig
2005-04-24 21:12 ` Jamie Lokier
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-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:19 ` Trond Myklebust
2005-04-26 15:29 ` Ritesh Kumar
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-26 15:24 ` Jamie Lokier
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 [this message]
2005-04-27 15:17 ` Jamie Lokier
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 13:36 ` Andi Kleen
2005-04-26 14:25 ` Trond Myklebust
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
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=20050427134331.GT5470@viasys.com \
--to=vherva@vianova.fi \
--cc=bulb@ucw.cz \
--cc=dedekind@oktetlabs.ru \
--cc=jamie@shareable.org \
--cc=john@stoffel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).