From: Nikolaus Rath <Nikolaus-BTH8mxji4b0@public.gmane.org>
To: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Cc: "fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org"
<fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
linux-fsdevel
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 0/10] fuse: An attempt to implement a write-back cache policy
Date: Wed, 04 Jul 2012 13:08:22 -0400 [thread overview]
Message-ID: <4FF47886.9040107@rath.org> (raw)
In-Reply-To: <4FF45447.5000705-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
On 07/04/2012 10:33 AM, Pavel Emelyanov wrote:
>>>>> A good solution of this is switching the FUSE page cache into a write-back policy.
>>>>> >>>> With this file data are pushed to the userspace with big chunks (depending on the
>>>>> >>>> dirty memory limits, but this is much more than 128k) which lets the FUSE daemons
>>>>> >>>> handle the size updates in a more efficient manner.
>>>>> >>>>
>>>>> >>>> The writeback feature is per-connection and is explicitly configurable at the
>>>>> >>>> init stage (is it worth making it CAP_SOMETHING protected?)
>>>> >>>
>>>> >>> From your description it sounds as if the only effect of write-back is
>>>> >>> to increase the chunk size. Why the need to require special
>>>> >>> privileges for this?
>>> >>
>>> >> Provided I understand the code correctly: if FUSE daemon turns writeback on and sets
>>> >> per-bdi dirty limit too high it can cause a deadlock on the box. Thus then daemon
>>> >> should be trusted by the kernel, i.e. -- privileged.
>> >
>> > Wouldn't it be more reasonable to enforce that the bdi dirty limit is
>> > not set too high then?
>
> Hardly, since if you have several mounts with small bdi limit each the sum of them
> can be still high.
Yeah, so isn't it possible to put a limit on the sum of them?
I think it would be much better if this could be made safe to use
instead of requiring special privileges. If that isn't possible,
wouldn't it be better to enable/disable the feature in /etc/fuse.conf,
similar to the user_allow_* options?
Having to explain how to assign capabilities in the documentation of a
fuse filesystem sounds quite dreadful to me...
Best,
-Nikolaus
PS: My naive attempt to apply your patches to my Debian 3.2 kernel
failed. I'm compiling 3.5rc5 at the moment - will see if I can get it to
boot afterwards...
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
next prev parent reply other threads:[~2012-07-04 17:08 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-03 15:53 [PATCH 0/10] fuse: An attempt to implement a write-back cache policy Pavel Emelyanov
2012-07-03 15:53 ` [PATCH 1/10] fuse: Linking file to inode helper Pavel Emelyanov
2012-07-03 15:54 ` [PATCH 2/10] fuse: Getting file for writeback helper Pavel Emelyanov
2012-07-03 15:54 ` [PATCH 3/10] fuse: Prepare to handle short reads Pavel Emelyanov
2012-07-03 15:55 ` [PATCH 4/10] fuse: Prepare to handle multiple pages in writeback Pavel Emelyanov
2012-07-04 13:06 ` Miklos Szeredi
2012-07-04 14:26 ` Pavel Emelyanov
2012-07-03 15:55 ` [PATCH 6/10] fuse: Trust kernel i_size only Pavel Emelyanov
2012-07-04 14:39 ` Miklos Szeredi
2012-07-05 14:10 ` Pavel Emelyanov
2012-07-10 5:53 ` Pavel Emelyanov
2012-07-13 16:30 ` Miklos Szeredi
2012-07-16 3:32 ` Pavel Emelyanov
2012-07-17 15:17 ` Miklos Szeredi
[not found] ` <8762a3pp3m.fsf-d8RdFUjzFsbxNFs70CDYszOMxtEWgIxa@public.gmane.org>
2012-10-01 17:30 ` Maxim V. Patlasov
2012-11-16 9:49 ` Miklos Szeredi
2012-11-16 10:32 ` Maxim V. Patlasov
2012-07-03 15:57 ` [PATCH 10/10] mm: Account for WRITEBACK_TEMP in balance_dirty_pages Pavel Emelyanov
[not found] ` <4FF3166B.5090800-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-13 16:57 ` Miklos Szeredi
2012-07-16 3:27 ` Pavel Emelyanov
2012-07-17 19:11 ` Miklos Szeredi
2012-07-27 4:01 ` Pavel Emelyanov
[not found] ` <5012127C.8070203-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-08-07 17:30 ` Miklos Szeredi
[not found] ` <4FF3156E.8030109-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-03 15:55 ` [PATCH 5/10] fuse: Connection bit for enabling writeback Pavel Emelyanov
2012-07-03 15:56 ` [PATCH 7/10] fuse: Flush files on wb close Pavel Emelyanov
2012-07-03 15:56 ` [PATCH 8/10] fuse: Implement writepages and write_begin/write_end callbacks Pavel Emelyanov
2012-07-03 15:57 ` [PATCH 9/10] fuse: Turn writeback on Pavel Emelyanov
2012-07-04 3:01 ` [PATCH 0/10] fuse: An attempt to implement a write-back cache policy Nikolaus Rath
[not found] ` <87a9zg1b7q.fsf-sKB8Sp2ER+yL2G7IJ6k9tw@public.gmane.org>
2012-07-04 7:11 ` Pavel Emelyanov
2012-07-04 13:22 ` Nikolaus Rath
[not found] ` <4FF4438B.8050807-BTH8mxji4b0@public.gmane.org>
2012-07-04 14:33 ` Pavel Emelyanov
[not found] ` <4FF45447.5000705-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-04 17:08 ` Nikolaus Rath [this message]
2012-07-05 9:01 ` Pavel Emelyanov
2012-07-05 13:07 ` Nikolaus Rath
2012-07-05 14:08 ` Pavel Emelyanov
2012-07-05 14:29 ` Nikolaus Rath
2012-07-05 14:34 ` Pavel Emelyanov
2012-07-06 2:04 ` Nikolaus Rath
[not found] ` <8762a1odbf.fsf-sKB8Sp2ER+yL2G7IJ6k9tw@public.gmane.org>
2012-07-06 8:46 ` Pavel Emelyanov
2012-07-05 19:31 ` Anand Avati
[not found] ` <4FF5EB85.1050701-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-07-05 20:07 ` Pavel Emelyanov
2012-07-06 11:52 ` [fuse-devel] " Kirill Korotaev
2012-07-05 19:26 ` Anand Avati
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=4FF47886.9040107@rath.org \
--to=nikolaus-bth8mxji4b0@public.gmane.org \
--cc=fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.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).