Re: [fuse-devel] fuse multi-threaded write bug

[Feng S. <ste...@gm...>]

Do you mean this patch?
http://sourceforge.net/mailarchive/message.php?msg_id=27511478

IMHO, we'd better keep this as a choice of the file system
implentations, not the fuse frame work. Or, providing this as
something like a "helper" library, not directly embedded to the
default fuse lib.

On Sat, Jan 19, 2013 at 4:52 PM, Ying Zhu <cas...@gm...> wrote:
> Hi Miklos,
> On Thu, Jan 17, 2013 at 1:10 AM, Miklos Szeredi <mi...@sz...> wrote:
>
>> On Fri, Oct 12, 2012 at 11:50 AM, YingHang Zhu <cas...@gm...>
>> wrote:
>> > Hi  Miklos and all:
>> >     I have seen some posts about running fuse in multi-threaded mode
>> would
>> > cause performance degrade in read and write. It's because the threads
>> holding
>> > requests running not in the same order as they get the requests.
>> >     Now I think this multi-threaded issue may also lead to data
>> corruption.
>> > Consider the following scenario:
>> >     The fuse file system get two request in fuse_kern_chan_receive. Both
>> of the
>> > requests write to the same offset of using the same file handle.
>> > Request 1 writes 1
>> > and request 2 writes 2. Now it will depends on the process scheduling
>> the final
>> > result will be. It can be 1 or 2.
>> >     This bug may occur in direct io mode because normally kernel will
>> cache the
>> > contents of the file.
>> >     Patch in this thread written by Michael McTernan can fix this bug.
>> >
>> http://sourceforge.net/mailarchive/forum.php?thread_name=87sjsdepoj.fsf%40tucsk.pomaz.szeredi.hu&forum_name=fuse-devel
>> >     Am I understanding this correctly or there existing some options
>> > to avoid this from happening?
>>
>> Writes are serialized in the kernel using i_mutex.
>>
>    Thanks for your explantion, I missed the locking and unlocking code of
> inode mutex
> in fuse_file_aio_write and fuse_direct_write previously. Yes fuse need some
> way to ensure its
> data consistency considering the process scheduling effect of userspace
> fuse fs daemons.
>    Locking the inode mutex in kernel may be a simple way, but it also
> forbids parallel writes to
> the same file, even with requests writing to different file offsets.
>
>>
>> Reads are not serialized and as pointed out in the referenced email
>> thread this may lead to performance problems (but not data
>> corruption).  I think the right solution to this is using a single
>> threaded event loop and dispatching to multiple processing threads
>> based on the file.  This can be done by the filesystem implementation
>> but I'm open to adding support to libfuse if there are enough users of
>> this feature.
>>
>      Michael's patch does exactly what you describes here, IMHO his patch
> can also preserve
> the order of write requests IOW data consistency without locking the mutex
> in kernel, thus improving
> the concurrency levels. Am I right or there exists some nasty corners in
> kernel stopping this concurrency
> from happening?
>
>>
>> Thanks,
>> Miklos
>
> --
> Thanks,
>      Ying Zhu
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122912
> _______________________________________________
> fuse-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-devel



-- 
Feng Shuo
Tel: (86)10-59851155-2116
Fax: (86)10-59851155-2008
Tianjin Zhongke Blue Whale Information Technologies Co., Ltd
10th Floor, Tower A, The GATE building, No. 19 Zhong-guan-cun Avenue
Haidian District, Beijing, China
Postcode 100080