From: Christian Stroetmann <stroetmann@ontolinux.com>
To: Olaf van der Spek <olafvdspek@gmail.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-ext4 <linux-ext4@vger.kernel.org>, Ted Ts'o <tytso@mit.edu>,
Ric Wheeler <rwheeler@redhat.com>,
Amir Goldstein <amir73il@gmail.com>
Subject: Re: Atomic file data replace API
Date: Wed, 29 Dec 2010 17:30:15 +0100 [thread overview]
Message-ID: <4D1B6217.6020300@ontolinux.com> (raw)
In-Reply-To: <AANLkTinV6Wx_8+gH0zMc7Av7z_LmyOQFbnmiek5oU1ku@mail.gmail.com>
On the 29.12.2010 16:35, Olaf van der Spek wrote:
> On Wed, Dec 29, 2010 at 4:30 PM, Christian Stroetmann
> <stroetmann@ontolinux.com> wrote:
>> On the 29.12.2010 13:42, Olaf van der Spek wrote:
>>>>> Not really, unfortunately. Haven't seen a single link to code that
>>>>> shows how to do it properly.
>> No, not this way. You were and still are asked for delivering the code.
>> Don't pervert the threat of the discussion.
> I'm talking about the code for temp file, fsync, rename. Not about
> O_ATOMIC code.
Maybe you have not understood the hints: It doesn't matter anymore about
what you are talking unless you present code.
>>> Each app makes it's own decision about what API to use. Supporting
>>> atomic stuff doesn't change the behaviour of existing apps.
>> Wrong, we are talking here in the first place about general atomic FS
>> operations. And to guarantee atomicity you have to change general FS
>> functions in such a way that in the end all other applications are affected,
> Why's that?
read the paragraph as a whole
>> or otherwise you have to implement an own (larger part of an) FS.
>> At this point there is no discussion anymore without code from you, because
>> this subject is as well discussed to the maximum in information
>> processing/informatics/computer science.
> This subject? Exactly what subject?
read the begining of the paragraph
>>> Maybe I should ask devs of some large apps on their take of this issue.
>> Nonsense, because they are already using:
>> a) the functions available by an FS,
> Of course. Does that mean the situation can't be improved for them?
Do you have any code that improves the situation to discuss here?
>> b) the functions available by a DBMS, or
>> c) a propritary special solution based on the available functions of the OS
>> and additional functionality that they develope and maintain themselves
>> for their comparable use cases since decades due to the cost vs. benefit
>> ratio.
> Olaf
Christian Stroetmann
next prev parent reply other threads:[~2010-12-29 16:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-27 11:51 Atomic file data replace API Olaf van der Spek
2010-12-27 13:20 ` Amir Goldstein
2010-12-27 15:53 ` Olaf van der Spek
2010-12-27 17:20 ` Amir Goldstein
2010-12-27 18:34 ` Olaf van der Spek
2010-12-28 2:59 ` Ted Ts'o
2010-12-28 17:27 ` Olaf van der Spek
2010-12-28 19:06 ` Ric Wheeler
2010-12-28 22:25 ` Olaf van der Spek
2010-12-28 22:36 ` Ric Wheeler
2010-12-28 22:58 ` Olaf van der Spek
2010-12-29 9:20 ` Amir Goldstein
2010-12-29 12:42 ` Olaf van der Spek
2010-12-29 15:30 ` Christian Stroetmann
2010-12-29 15:35 ` Olaf van der Spek
2010-12-29 16:30 ` Christian Stroetmann [this message]
2010-12-29 17:12 ` Olaf van der Spek
2010-12-29 17:15 ` Greg Freemyer
2010-12-29 19:30 ` Christian Stroetmann
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=4D1B6217.6020300@ontolinux.com \
--to=stroetmann@ontolinux.com \
--cc=amir73il@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=olafvdspek@gmail.com \
--cc=rwheeler@redhat.com \
--cc=tytso@mit.edu \
/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).