[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] filesystem guarantees for multi-threaded access
From:       Goswin von Brederlow <goswin-v-b () web ! de>
Date:       2011-10-05 13:23:32
Message-ID: 87vcs3po6j.fsf () frosties ! localnet
[Download RAW message or body]

Han-Wen Nienhuys <hanwenn@gmail.com> writes:

> On Sun, Oct 2, 2011 at 3:28 PM, Stefan Westerfeld <stefan@space.twc.de> wrote:
>
>> I wonder what guarantees a filesystem has to give when more than one thread is
>> involved. For instance, if thread 1 and thread 2 access the same file, and
>>
>>  thread 1 - writes ("thread 1") to file foo
>>  thread 2 - writes ("thread 2") to file foo, a tiny bit later
>>
>> does a filesystem have to guarantee that the file foo contains "thread 2" after
>> this?
>
> No, if userland wants to have guarantees about ordering, it should
> issue the 2nd write after the 1st write returns, in which case the
> fuse FS will not process them simultaneously.

Or in other words: This is not something your filesystem has to or even
can do anything about. This issue already gives random results in the
kernel and the fuse filesystem only sees the final result, not the
individual writes (if they are close enough together).

MfG
        Goswin

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel


[prev in list] [next in list] [prev in thread] [next in thread]