From: Jan Hudec <bulb@ucw.cz>
To: "Artem B. Bityuckiy" <dedekind@oktetlabs.ru>
Cc: Jamie Lokier <jamie@shareable.org>,
Trond Myklebust <trond.myklebust@fys.uio.no>,
John Stoffel <john@stoffel.org>, Ville Herva <v@iki.fi>,
Linux Filesystem Development <linux-fsdevel@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: filesystem transactions API
Date: Wed, 27 Apr 2005 11:14:03 +0200 [thread overview]
Message-ID: <20050427091402.GA1904@vagabond> (raw)
In-Reply-To: <426E65E9.5070306@oktetlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]
On Tue, Apr 26, 2005 at 20:01:45 +0400, Artem B. Bityuckiy wrote:
> Jamie Lokier wrote:
> >No. Why would you block? You can have transactions without blocking
> >other processes.
> >
> >When updating, say, the core-utils package (which contains cat),
> >there's no reason why a program which executes "cat" should have to
> >block during the update. It can simply execute the old one until the
> >new one is committed at the end of the update.
> >
> >It's analogous to RCU for protecting kernel data structures without
> >blocking readers.
> >
> Hmm, can't we implement a user-space locking system which admits of
> readers during transactions? I gues we can.
The problem with implementing in userland, as was already said in the
thread, is, that if some process does not use the library, it can
completely mess it up. It is only safe in kernel.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-04-27 9:15 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 [this message]
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
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=20050427091402.GA1904@vagabond \
--to=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 \
--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 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).