Re: [fuse-devel] HSFS v0.2 release

[Feng Shuo <steve.shuo.feng@gm...>]

Thanks Lucas' reminder. Since I'm using some Linux kernel codes which
are GPLv2, I switched the license of HSFS back to GPLv2 to avoid
touching those incompatible things. I also fixed some bugs but I won't
do more testing especially with write back cache because it's mainly
for local file system.

Now v0.2 could be finalized:-). The new github project at:
    http://openunix.github.com/hsfs/
Packages (RPM) wiki:
    https://github.com/openunix/hsfs/wiki/RPMDistributions
OpenSUSE Build Service:
    https://build.opensuse.org/project/show?project=home%3Afengshuo%3Ahsfs

I will review the FUSE readdirplus patch and try to support it in next
version of HSFS.

On Fri, Nov 23, 2012 at 11:59 AM, Feng Shuo <steve.shuo.feng@...> wrote:
> BTW. I did a quick dd test on my desktop computer:
> .........
> /dev/fuse           60600040  55391772   2129940  97% /nfs/g
> localhost:/nfs/uml  60600040  55391772   2129940  97% /nfs/g
> bogon:/nfs/g # dd if=/dev/zero of=test bs=1M count=10K
> 10240+0 records in
> 10240+0 records out
> 10737418240 bytes (11 GB) copied, 564.701 s, 19.0 MB/s
> bogon:/nfs/g # dd of=/dev/zero if=test bs=1M count=10K
> 10240+0 records in
> 10240+0 records out
> 10737418240 bytes (11 GB) copied, 173.235 s, 62.0 MB/s
>
> The read performance seems good enough with a SATA drive but the write
> is poor, I believe it's because of no write cache. I will look into
> Maxim's write cache patch and have a try if I get time.
>
> It will be very interesting to see if current write cache mechanism
> can support NFS caching mechanism......
>
> On Fri, Nov 23, 2012 at 11:43 AM, Feng Shuo <steve.shuo.feng@...> wrote:
>> Hi guys,
>>
>> The FUSE based NFSv3 client gets a new alpha version now. In this version I
>> decouple the fuse_ino_t and nfs3 fileid to support hard link and resolve the
>> stale file handle issue.
>>
>> To do this I steal some Linux kernel codes but at least FUSE framework is
>> proved the ability to support NFS or NFS-link file system implementations.
>> :-)
>>
>> The project page is at: https://github.com/openunix/hsfs.
>>
>> RPMs are also available on openSUSE build service (although I don't think
>> there are anybody really want to use it:-). Please refer to the HSFS wiki
>> for more details: https://github.com/openunix/hsfs/wiki
>>
>> Now it is just a nightly build by the Git snapshot. I will do more cleanup
>> in codes and then provide the final version of v0.2 release soon.
>>
>> --
>> 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
>>
>
>
>
> --
> 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



-- 
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

Re: [fuse-devel] [PATCH v2 00/14] fuse: An attempt to implement a write-back cache policy

[Brian Foster <bfoster@re...>]

On 11/28/2012 12:29 AM, Maxim V. Patlasov wrote:
> Hi Brian,
> 
> 11/28/2012 12:44 AM, Brian Foster пишет:
>> On 11/27/2012 02:56 AM, Maxim V. Patlasov wrote:
>>> Hi Feng,
>>>
>>> 11/27/2012 05:04 AM, Feng Shuo пишет:
>>>> Hi Maxim,
>>>>
>> ...
>>> The patch-set follows the model "trust kernel i_size only". This works
>>> fine at least in case of userspace fuse wtih exclusive write semantics.
>>> In case of mutual concurrent internal/external read/write access, sysad
>>> should not turn the feature on (it's turned off by default). I wouldn't
>>> like to complicate the patch-set further adding bits for that case. This
>>> area is opened for future enhancements :)
>>>
>> Hi Maxim,
>>
>> I started looking at this set, not enough to comment yet, but since Feng
>> brought it up I had a similar question...
>>
>> I thought you or Miklos eluded to an NFS-like approach of flushing the
>> local dirty data on getattr to ensure the inode size was up to date. Out
>> of curiosity (even if that will not be part of this set initially), was
>> that considered too problematic for some reason (i.e., complexity,
>> performance)? Thanks.
> 
> Exactly for reasons Feng mentioned -- simple "ls" should not kill
> performance and get blocked for long on heavy loaded node. Having in
> mind to use FUSE in production and with bdi dirty limit much more than
> 1%, well... flushing a few gigabytes of dirty memory on remote storage
> over congested network would be unacceptable big amount of work for to
> complete "ls".
> 

Ok, makes sense. I guess we'll have to resort to that for non-local
filesystems, but I see no reason it couldn't be added later as an
option. Thanks for the info!

Brian

> Thanks,
> Maxim

Re: [fuse-devel] howto share directories (inode, entry) between processes.

[Feng Shuo <steve.shuo.feng@gm...>]

Thank you Stef. I think I understand now :-).


On Wed, Nov 28, 2012 at 2:36 AM, Stef Bon <stefbon@...> wrote:

> 2012/11/27 Feng Shuo <steve.shuo.feng@...>:
> > Hi Stef,
> >
> > Thank you for your detail explanation :-). I also read your post at
> > http://pl.digipedia.org/usenet/thread/15030/3958/. My understanding is
> > notifyfs is not a filesystem implemented through FUSE but actually a file
> > system event monitoring framework. It could:
> >
> > Monitor a local file system by inotify.
>
> Hi, yes, that's my intention. I'm making it possible that on other
> systems it uses the fs notify on that system.
>
> And yes, notifyfs is not a real filesystem, but the FUSE framework
> offers a very good framework to create a fs event service. It 's not
> my intention that client can access the mountpoint of notifyfs, which
> is actually very silly.
>
> > In future, monitor the remote file events on the cifs server by some
> > extended API. ---- This makes sense because inotify doesn't really
> support
> > any distributed file system even though SMB has this support in its
> > protocol.
>
> Yes, that's my intention. Some remarks:
>
> - I've created a fsevent api, independend of the system. I've used the
> inotify API first, but that was too simple. My intention is to publish
> this soon on the the project website:
>
> https://github.com/stefbon/notifyfs
>
> - filesystems like FUSE and cifs and nfs do support inotify. Yes, but
> that only counts for local changes, not in the backend. Fuse fs's and
> cifs and nfs do not "know" a watch has been set, and so do not take
> action to contact the backend.
>
> - when a client sets a watch, it does not know the filesystem (for
> example cifs), and does not know how to deal with it. At this moment
> notifyfs does not do anything, but it's my intention to "forward" the
> watch to the filesystem. Then the filesystem can do the backend/API
> specific call to set the watch, and send any result back to notifyfs,
> which on his turn will inform the clients.
>
> This forwarding looks overcomplicated, but I think this is necessary.
> The filesystem has probably used some way of credentials or ticket,
> which was required to get access to the backend. Now notifyfs does not
> have access to these credentials/ticket, so will not get access to the
> backend just that easy.
>
> And second, the filesystem self can take action when something occurs
> on the backend, like when a directory is removed, with all it's
> contents. The filesystem should correct it's own inode/entry cache.
> When informed by the backend this way, it can do that directly.
>
> In the past I did some experiments with a notifyfs process on the
> remote host, which can offer information, when permissions are not
> taken into account. I did not finish it, but I'm sure it should work.
> I did this using sshfs, and notifyfs finds out what server is the
> backend.
>
>
> - I've contacted the developers of the kernel fs nfs, and they have
> written me that NFS supports some basic fs change notify.
>
> >
> > Back to your question, frankly I don't think it will be a good idea to
> > introduce another pipe/shm or anything else between fuse instance and
> > another process (here it's notifyfs), because fuse itself is actually the
> > "pipe" for that already, right? The fuse as the pipe should be fast and
> > efficient for this purpose. Even if not we could enhance it instead of
> > making another "pipe". :-)
>
> I do not understand you. The shared memory notifyfs maintains is a
> cache of entries gui clients can use, and get information from.
>
> The .directory file contains info about a directory, about the icon.
> Try it in KDE, and adjust the icon of a directory.
>
> But I'm very glad with your reactions. I'm working on this myself, and
> I do not like that.
>
> Futher I want to try it with your FUSE nfs client fs, before trying
> the in kernel fs nfs.
>
> Stef
>



-- 
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

Re: [fuse-devel] [PATCH v2 00/14] fuse: An attempt to implement a write-back cache policy

[Maxim V. Patlasov <mpatlasov@pa...>]

Hi Brian,

11/28/2012 12:44 AM, Brian Foster пишет:
> On 11/27/2012 02:56 AM, Maxim V. Patlasov wrote:
>> Hi Feng,
>>
>> 11/27/2012 05:04 AM, Feng Shuo пишет:
>>> Hi Maxim,
>>>
> ...
>> The patch-set follows the model "trust kernel i_size only". This works
>> fine at least in case of userspace fuse wtih exclusive write semantics.
>> In case of mutual concurrent internal/external read/write access, sysad
>> should not turn the feature on (it's turned off by default). I wouldn't
>> like to complicate the patch-set further adding bits for that case. This
>> area is opened for future enhancements :)
>>
> Hi Maxim,
>
> I started looking at this set, not enough to comment yet, but since Feng
> brought it up I had a similar question...
>
> I thought you or Miklos eluded to an NFS-like approach of flushing the
> local dirty data on getattr to ensure the inode size was up to date. Out
> of curiosity (even if that will not be part of this set initially), was
> that considered too problematic for some reason (i.e., complexity,
> performance)? Thanks.

Exactly for reasons Feng mentioned -- simple "ls" should not kill 
performance and get blocked for long on heavy loaded node. Having in 
mind to use FUSE in production and with bdi dirty limit much more than 
1%, well... flushing a few gigabytes of dirty memory on remote storage 
over congested network would be unacceptable big amount of work for to 
complete "ls".

Thanks,
Maxim

Re: [fuse-devel] [PATCH v2 00/14] fuse: An attempt to implement a write-back cache policy

[Feng Shuo <steve.shuo.feng@gm...>]

Hmm. I agree on this. The NFS flush-on-getattr is mainly to:

   1. Get the latest mtime from server - This is because, by default, NFS
   doesn't trust local time but use server time for all the file system
   concept.
   2. Get the real i_blocks/st_blocks - There is no concept of
   prepare_write in NFS except pNFS (a draft of v4.1), so there is no
   allocation unless you flush out everything.
   3. Get the correct i_size - I guess this is just a kind of security and
   consistency concerning.

Actually, considering only support local file system, we don't need to care
about #1 and #3(correct me if I'm wrong). If we don't think #2 is that
important, or as a trade-off, we don't need the flush-on-getattr. This is
mainly because, from my experience, the flush-on-getattr is a very painful
part of NFS. That means if you are writing /path/to/file, simply do a "ls
/path/to" will kill the performance and got blocked for long time.:-(


On Wed, Nov 28, 2012 at 4:44 AM, Brian Foster <bfoster@...> wrote:

> On 11/27/2012 02:56 AM, Maxim V. Patlasov wrote:
> > Hi Feng,
> >
> > 11/27/2012 05:04 AM, Feng Shuo пишет:
> >> Hi Maxim,
> >>
> ...
> >
> > The patch-set follows the model "trust kernel i_size only". This works
> > fine at least in case of userspace fuse wtih exclusive write semantics.
> > In case of mutual concurrent internal/external read/write access, sysad
> > should not turn the feature on (it's turned off by default). I wouldn't
> > like to complicate the patch-set further adding bits for that case. This
> > area is opened for future enhancements :)
> >
>
> Hi Maxim,
>
> I started looking at this set, not enough to comment yet, but since Feng
> brought it up I had a similar question...
>
> I thought you or Miklos eluded to an NFS-like approach of flushing the
> local dirty data on getattr to ensure the inode size was up to date. Out
> of curiosity (even if that will not be part of this set initially), was
> that considered too problematic for some reason (i.e., complexity,
> performance)? Thanks.
>
> Brian
>
> > Thanks,
> > Maxim
> >
> >
> ------------------------------------------------------------------------------
> > Monitor your physical, virtual and cloud infrastructure from a single
> > web console. Get in-depth insight into apps, servers, databases, vmware,
> > SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> > Pricing starts from $795 for 25 servers or applications!
> > http://p.sf.net/sfu/zoho_dev2dev_nov
> > _______________________________________________
> > fuse-devel mailing list
> > fuse-devel@...
> > 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

Re: [fuse-devel] [PATCH v2 00/14] fuse: An attempt to implement a write-back cache policy

[Brian Foster <bfoster@re...>]

On 11/27/2012 02:56 AM, Maxim V. Patlasov wrote:
> Hi Feng,
> 
> 11/27/2012 05:04 AM, Feng Shuo пишет:
>> Hi Maxim,
>>
...
> 
> The patch-set follows the model "trust kernel i_size only". This works 
> fine at least in case of userspace fuse wtih exclusive write semantics. 
> In case of mutual concurrent internal/external read/write access, sysad 
> should not turn the feature on (it's turned off by default). I wouldn't 
> like to complicate the patch-set further adding bits for that case. This 
> area is opened for future enhancements :)
> 

Hi Maxim,

I started looking at this set, not enough to comment yet, but since Feng
brought it up I had a similar question...

I thought you or Miklos eluded to an NFS-like approach of flushing the
local dirty data on getattr to ensure the inode size was up to date. Out
of curiosity (even if that will not be part of this set initially), was
that considered too problematic for some reason (i.e., complexity,
performance)? Thanks.

Brian

> Thanks,
> Maxim
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> fuse-devel mailing list
> fuse-devel@...
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
> 

Re: [fuse-devel] howto share directories (inode, entry) between processes.

[Stef Bon <stefbon@gm...>]

2012/11/27 Feng Shuo <steve.shuo.feng@...>:
> Hi Stef,
>
> Thank you for your detail explanation :-). I also read your post at
> http://pl.digipedia.org/usenet/thread/15030/3958/. My understanding is
> notifyfs is not a filesystem implemented through FUSE but actually a file
> system event monitoring framework. It could:
>
> Monitor a local file system by inotify.

Hi, yes, that's my intention. I'm making it possible that on other
systems it uses the fs notify on that system.

And yes, notifyfs is not a real filesystem, but the FUSE framework
offers a very good framework to create a fs event service. It 's not
my intention that client can access the mountpoint of notifyfs, which
is actually very silly.

> In future, monitor the remote file events on the cifs server by some
> extended API. ---- This makes sense because inotify doesn't really support
> any distributed file system even though SMB has this support in its
> protocol.

Yes, that's my intention. Some remarks:

- I've created a fsevent api, independend of the system. I've used the
inotify API first, but that was too simple. My intention is to publish
this soon on the the project website:

https://github.com/stefbon/notifyfs

- filesystems like FUSE and cifs and nfs do support inotify. Yes, but
that only counts for local changes, not in the backend. Fuse fs's and
cifs and nfs do not "know" a watch has been set, and so do not take
action to contact the backend.

- when a client sets a watch, it does not know the filesystem (for
example cifs), and does not know how to deal with it. At this moment
notifyfs does not do anything, but it's my intention to "forward" the
watch to the filesystem. Then the filesystem can do the backend/API
specific call to set the watch, and send any result back to notifyfs,
which on his turn will inform the clients.

This forwarding looks overcomplicated, but I think this is necessary.
The filesystem has probably used some way of credentials or ticket,
which was required to get access to the backend. Now notifyfs does not
have access to these credentials/ticket, so will not get access to the
backend just that easy.

And second, the filesystem self can take action when something occurs
on the backend, like when a directory is removed, with all it's
contents. The filesystem should correct it's own inode/entry cache.
When informed by the backend this way, it can do that directly.

In the past I did some experiments with a notifyfs process on the
remote host, which can offer information, when permissions are not
taken into account. I did not finish it, but I'm sure it should work.
I did this using sshfs, and notifyfs finds out what server is the
backend.


- I've contacted the developers of the kernel fs nfs, and they have
written me that NFS supports some basic fs change notify.

>
> Back to your question, frankly I don't think it will be a good idea to
> introduce another pipe/shm or anything else between fuse instance and
> another process (here it's notifyfs), because fuse itself is actually the
> "pipe" for that already, right? The fuse as the pipe should be fast and
> efficient for this purpose. Even if not we could enhance it instead of
> making another "pipe". :-)

I do not understand you. The shared memory notifyfs maintains is a
cache of entries gui clients can use, and get information from.

The .directory file contains info about a directory, about the icon.
Try it in KDE, and adjust the icon of a directory.

But I'm very glad with your reactions. I'm working on this myself, and
I do not like that.

Futher I want to try it with your FUSE nfs client fs, before trying
the in kernel fs nfs.

Stef

Re: [fuse-devel] howto share directories (inode, entry) between processes.

[Ying Zhu <casualfisher@gm...>]

Hi Stef,

On Tue, Nov 27, 2012 at 6:12 PM, Stef Bon <stefbon@...> wrote:
> 2012/11/27 Feng Shuo <steve.shuo.feng@...>:
>> Hi Stef,
>>
>> IMHO, if notifyfs is a fs just for 'notify', there must be an
>> under-layer fs to provide the storage. So after the client get the
>> notification, how about it directly read the content of the dir from
>> the under-layer fs?
>>
>
> Hi,
>
> reading from the underlying fs is possible, if notifyfs is only an fs
> event notifier. But it isn't, well I'm working on extending it's
> abilities.
>
> I've been working on a bug in Dolphin, the filemanager of KDE. And the
> problem was that with the current implementation the loading if the
> mimetype/icon and the special .directory file with some filesystems is
> very slow. That made the developers disable the loading of this
> additional info for network filesystems and fuse fs's.
> This lead to some critics of users, who very much wanted to get the
> loading for for example nfs back.
>
> Now I've tried to fix this, but I'm not a c++ programmer, and so I had
> too much trouble even understanding tho code.
> But what I decided to do is work on notifyfs which offers various
> services to gui clients.
>
> Watching filesystem events is one of them.
> But also, at this moment I do cache the contents of a directory in
> shared memory, so gui clients can build the contents of their views.
> Apart from basic information like name, mode, uid, gid, size and
> timestamps, notifyfs will also offer additional info like mimetype,
> icon and .directory file when clients are interested. Background
> threads and io between server and clients will do the job.
If I understand you and Feng correctly, I could layer notifyfs like this:

                                   |     |      |        |
registered processes

Userspace        notifyfs(caching name, mode, uid, mimetype...)
________________________________________________________

Kernel                                  fuse
                                       ext3/ext4/cifs/nfs
As Feng said notifying the registered processes calls for some mechanisms
like inotify of NFS and CIFS. The notifyfs can pull some data in to
get mimetype
and other information once fuse reminds that something has changed. The notifyfs
daemon should keep the inode/entry/directory on behalf of all
registered processes
(clients) and if a registered process directly ask the notifyfs dameon
for data.
I do not quite understand why you said the client must have a
inode/entry tree, if it's for
performance reason the registered processes can keep it own cache and
get notification sent
by the notifyfs daemon in case of synchronization instead of polling
for changes.
>
> I'm testing it's offers more flexibility and performance. So I'm not
> sure it offers real improvments, but I'm working on it and willing to
> test.
>
> Futhermore I want to make the fsevent system work with FUSE
> filesystems (like yours) and kernel network filesystems like NFS and
> CIFS.
> (the latest will be very difficult, but not impossible, since NFS and
> CIFS are in kernel space, and notifyfs is in userspace. I'm thinking
> about netlink to communicate between these).
>
> And it's can also watch mount events (by watching
> /proc/self/mountinfo) and store everything in shared memory, and send
> clients a message when something has changed. Now almost every client
> has it's own watch mechanism.
>
> Stef Bon
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> fuse-devel mailing list
> fuse-devel@...
> https://lists.sourceforge.net/lists/listinfo/fuse-devel



-- 
Thanks,
     Ying Zhu

Re: [fuse-devel] howto share directories (inode, entry) between processes.

[Feng Shuo <steve.shuo.feng@gm...>]

Hi Stef,

Thank you for your detail explanation :-). I also read your post at
http://pl.digipedia.org/usenet/thread/15030/3958/. My understanding is
notifyfs is not a filesystem implemented through FUSE but actually a file
system event monitoring framework. It could:

   1. Monitor a local file system by inotify.
   2. In future, monitor the remote file events on the cifs server by some
   extended API. ---- This makes sense because inotify doesn't really support
   any distributed file system even though SMB has this support in its
   protocol.
   3. Monitor the file system on the NFS server side. ---- IMHO, this is
   not doable because there is no such support in NFS protocol. You could only
   treat it as a local file system (which means you won't get any notification
   if the file is changed by other clients or on the server locally).
   4. FUSE ---- I don't quite understand this because I believe FUSE
   support inotify. Do you want similar remote monitoring support as in CIFS?
   I thing that will heavily depend on the FUSE file system implementation not
   FUSE framework.

Back to your question, frankly I don't think it will be a good idea to
introduce another pipe/shm or anything else between fuse instance and
another process (here it's notifyfs), because fuse itself is actually the
"pipe" for that already, right? The fuse as the pipe should be fast
and efficient for this purpose. Even if not we could enhance it instead of
making another "pipe". :-)

BTW. Do you know why the loading of the special .directory file is slow?
I'm not quite familiar with KDE (although I'm a KDE user :-).


On Tue, Nov 27, 2012 at 6:12 PM, Stef Bon <stefbon@...> wrote:

> 2012/11/27 Feng Shuo <steve.shuo.feng@...>:
> > Hi Stef,
> >
> > IMHO, if notifyfs is a fs just for 'notify', there must be an
> > under-layer fs to provide the storage. So after the client get the
> > notification, how about it directly read the content of the dir from
> > the under-layer fs?
> >
>
> Hi,
>
> reading from the underlying fs is possible, if notifyfs is only an fs
> event notifier. But it isn't, well I'm working on extending it's
> abilities.
>
> I've been working on a bug in Dolphin, the filemanager of KDE. And the
> problem was that with the current implementation the loading if the
> mimetype/icon and the special .directory file with some filesystems is
> very slow. That made the developers disable the loading of this
> additional info for network filesystems and fuse fs's.
> This lead to some critics of users, who very much wanted to get the
> loading for for example nfs back.
>
> Now I've tried to fix this, but I'm not a c++ programmer, and so I had
> too much trouble even understanding tho code.
> But what I decided to do is work on notifyfs which offers various
> services to gui clients.
>
> Watching filesystem events is one of them.
> But also, at this moment I do cache the contents of a directory in
> shared memory, so gui clients can build the contents of their views.
> Apart from basic information like name, mode, uid, gid, size and
> timestamps, notifyfs will also offer additional info like mimetype,
> icon and .directory file when clients are interested. Background
> threads and io between server and clients will do the job.
>
> I'm testing it's offers more flexibility and performance. So I'm not
> sure it offers real improvments, but I'm working on it and willing to
> test.
>
> Futhermore I want to make the fsevent system work with FUSE
> filesystems (like yours) and kernel network filesystems like NFS and
> CIFS.
> (the latest will be very difficult, but not impossible, since NFS and
> CIFS are in kernel space, and notifyfs is in userspace. I'm thinking
> about netlink to communicate between these).
>
> And it's can also watch mount events (by watching
> /proc/self/mountinfo) and store everything in shared memory, and send
> clients a message when something has changed. Now almost every client
> has it's own watch mechanism.
>
> Stef Bon
>



-- 
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

Re: [fuse-devel] [PATCH v2 00/14] fuse: An attempt to implement a write-back cache policy

[Feng Shuo <steve.shuo.feng@gm...>]

Thank you Maxim. This is very much clear and makes sense for me.


On Tue, Nov 27, 2012 at 3:56 PM, Maxim V. Patlasov
<mpatlasov@...>wrote:

> Hi Feng,
>
> 11/27/2012 05:04 AM, Feng Shuo пишет:
>
>  Hi Maxim,
>>
>> I'm new to fuse but have some experience with NFS. From my
>> understanding after reviewing your patchset, it seems only work with
>> local file system or a distributed file system whose file is never
>> modified (could be grown but no or very few modified) because it
>> doesn't exam the pre/post status of the writing object (e.g. a file).
>> So if a file is modified outside, fuse might not get any chance to
>> handle it...... Correct me if I got wrong since I'm really new to
>> fuse. :-)
>>
>
> This topic was discussed when Pavel sent initial version of patches (you
> can find it in fuse-devel archives). Brian asked:
>
>  Would this pose a problem for a filesystem in which the size of the
>> inode can change remotely (i.e., not visible to the local instance of
>> fuse)? I haven't tested this, but it seems like it could be an issue
>> based on the implementation.
>>
>
> And Pavel replied:
>
>  Yes, it will. The model of i_size management I implemented here is based
>> on an assumption that the userspace is just a storage for data and should
>> catch up with the kernel i_size value. In order to make it possible for
>> user
>> space to update i_size in kernel we'd have to implement some (probably)
>> tricky algorithm, I haven't yet thought about it.
>>
>
> The patch-set follows the model "trust kernel i_size only". This works
> fine at least in case of userspace fuse wtih exclusive write semantics. In
> case of mutual concurrent internal/external read/write access, sysad should
> not turn the feature on (it's turned off by default). I wouldn't like to
> complicate the patch-set further adding bits for that case. This area is
> opened for future enhancements :)
>
> Thanks,
> Maxim
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...
> More majordomo info at  http://vger.kernel.org/**majordomo-info.html<http://vger.kernel.org/majordomo-info.html>;
>



-- 
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

Re: [fuse-devel] howto share directories (inode, entry) between processes.

[Stef Bon <stefbon@gm...>]

2012/11/27 Feng Shuo <steve.shuo.feng@...>:
> Hi Stef,
>
> IMHO, if notifyfs is a fs just for 'notify', there must be an
> under-layer fs to provide the storage. So after the client get the
> notification, how about it directly read the content of the dir from
> the under-layer fs?
>

Hi,

reading from the underlying fs is possible, if notifyfs is only an fs
event notifier. But it isn't, well I'm working on extending it's
abilities.

I've been working on a bug in Dolphin, the filemanager of KDE. And the
problem was that with the current implementation the loading if the
mimetype/icon and the special .directory file with some filesystems is
very slow. That made the developers disable the loading of this
additional info for network filesystems and fuse fs's.
This lead to some critics of users, who very much wanted to get the
loading for for example nfs back.

Now I've tried to fix this, but I'm not a c++ programmer, and so I had
too much trouble even understanding tho code.
But what I decided to do is work on notifyfs which offers various
services to gui clients.

Watching filesystem events is one of them.
But also, at this moment I do cache the contents of a directory in
shared memory, so gui clients can build the contents of their views.
Apart from basic information like name, mode, uid, gid, size and
timestamps, notifyfs will also offer additional info like mimetype,
icon and .directory file when clients are interested. Background
threads and io between server and clients will do the job.

I'm testing it's offers more flexibility and performance. So I'm not
sure it offers real improvments, but I'm working on it and willing to
test.

Futhermore I want to make the fsevent system work with FUSE
filesystems (like yours) and kernel network filesystems like NFS and
CIFS.
(the latest will be very difficult, but not impossible, since NFS and
CIFS are in kernel space, and notifyfs is in userspace. I'm thinking
about netlink to communicate between these).

And it's can also watch mount events (by watching
/proc/self/mountinfo) and store everything in shared memory, and send
clients a message when something has changed. Now almost every client
has it's own watch mechanism.

Stef Bon

Re: [fuse-devel] [PATCH v2 00/14] fuse: An attempt to implement a write-back cache policy

[Maxim V. Patlasov <mpatlasov@pa...>]

Hi Feng,

11/27/2012 05:04 AM, Feng Shuo пишет:
> Hi Maxim,
>
> I'm new to fuse but have some experience with NFS. From my
> understanding after reviewing your patchset, it seems only work with
> local file system or a distributed file system whose file is never
> modified (could be grown but no or very few modified) because it
> doesn't exam the pre/post status of the writing object (e.g. a file).
> So if a file is modified outside, fuse might not get any chance to
> handle it...... Correct me if I got wrong since I'm really new to
> fuse. :-)

This topic was discussed when Pavel sent initial version of patches (you 
can find it in fuse-devel archives). Brian asked:

> Would this pose a problem for a filesystem in which the size of the
> inode can change remotely (i.e., not visible to the local instance of
> fuse)? I haven't tested this, but it seems like it could be an issue
> based on the implementation.

And Pavel replied:

> Yes, it will. The model of i_size management I implemented here is based
> on an assumption that the userspace is just a storage for data and should
> catch up with the kernel i_size value. In order to make it possible for user
> space to update i_size in kernel we'd have to implement some (probably)
> tricky algorithm, I haven't yet thought about it.

The patch-set follows the model "trust kernel i_size only". This works 
fine at least in case of userspace fuse wtih exclusive write semantics. 
In case of mutual concurrent internal/external read/write access, sysad 
should not turn the feature on (it's turned off by default). I wouldn't 
like to complicate the patch-set further adding bits for that case. This 
area is opened for future enhancements :)

Thanks,
Maxim

Re: [fuse-devel] [PATCH v2 00/14] fuse: An attempt to implement a write-back cache policy

[Feng Shuo <steve.shuo.feng@gm...>]

Hi Maxim,

I'm new to fuse but have some experience with NFS. From my
understanding after reviewing your patchset, it seems only work with
local file system or a distributed file system whose file is never
modified (could be grown but no or very few modified) because it
doesn't exam the pre/post status of the writing object (e.g. a file).
So if a file is modified outside, fuse might not get any chance to
handle it...... Correct me if I got wrong since I'm really new to
fuse. :-)

On Sat, Nov 17, 2012 at 1:04 AM, Maxim Patlasov <mpatlasov@...> wrote:
> Hi,
>
> This is the second iteration of Pavel Emelyanov's patch-set implementing
> write-back policy for FUSE page cache. Initial patch-set description was
> the following:
>
> One of the problems with the existing FUSE implementation is that it uses the
> write-through cache policy which results in performance problems on certain
> workloads. E.g. when copying a big file into a FUSE file the cp pushes every
> 128k to the userspace synchronously. This becomes a problem when the userspace
> back-end uses networking for storing the data.
>
> 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?) When the writeback is
> turned ON:
>
> * still copy writeback pages to temporary buffer when sending a writeback request
>   and finish the page writeback immediately
>
> * make kernel maintain the inode's i_size to avoid frequent i_size synchronization
>   with the user space
>
> * take NR_WRITEBACK_TEMP into account when makeing balance_dirty_pages decision.
>   This protects us from having too many dirty pages on FUSE
>
> The provided patchset survives the fsx test. Performance measurements are not yet
> all finished, but the mentioned copying of a huge file becomes noticeably faster
> even on machines with few RAM and doesn't make the system stuck (the dirty pages
> balancer does its work OK). Applies on top of v3.5-rc4.
>
> We are currently exploring this with our own distributed storage implementation
> which is heavily oriented on storing big blobs of data with extremely rare meta-data
> updates (virtual machines' and containers' disk images). With the existing cache
> policy a typical usage scenario -- copying a big VM disk into a cloud -- takes way
> too much time to proceed, much longer than if it was simply scp-ed over the same
> network. The write-back policy (as I mentioned) noticeably improves this scenario.
> Kirill (in Cc) can share more details about the performance and the storage concepts
> details if required.
>
> Changed in v2:
>  - numerous bugfixes:
>    - fuse_write_begin and fuse_writepages_fill and fuse_writepage_locked must wait
>      on page writeback because page writeback can extend beyond the lifetime of
>      the page-cache page
>    - fuse_send_writepages can end_page_writeback on original page only after adding
>      request to fi->writepages list; otherwise another writeback may happen inside
>      the gap between end_page_writeback and adding to the list
>    - fuse_direct_io must wait on page writeback; otherwise data corruption is possible
>      due to reordering requests
>    - fuse_flush must flush dirty memory and wait for all writeback on given inode
>      before sending FUSE_FLUSH to userspace; otherwise FUSE_FLUSH is not reliable
>    - fuse_file_fallocate must hold i_mutex around FUSE_FALLOCATE and i_size update;
>      otherwise a race with a writer extending i_size is possible
>    - fix handling errors in fuse_writepages and fuse_send_writepages
>  - handle i_mtime intelligently if writeback cache is on (see patch #7 (update i_mtime
>    on buffered writes) for details.
>  - put enabling writeback cache under fusermount control; (see mount option
>    'allow_wbcache' introduced by patch #13 (turn writeback cache on))
>  - rebased on v3.7-rc5
>
> Thanks,
> Maxim
>
> ---
>
> Maxim Patlasov (14):
>       fuse: Linking file to inode helper
>       fuse: Getting file for writeback helper
>       fuse: Prepare to handle short reads
>       fuse: Prepare to handle multiple pages in writeback
>       fuse: Connection bit for enabling writeback
>       fuse: Trust kernel i_size only
>       fuse: Update i_mtime on buffered writes
>       fuse: Flush files on wb close
>       fuse: Implement writepages and write_begin/write_end callbacks
>       fuse: fuse_writepage_locked() should wait on writeback
>       fuse: fuse_flush() should wait on writeback
>       fuse: Fix O_DIRECT operations vs cached writeback misorder
>       fuse: Turn writeback cache on
>       mm: Account for WRITEBACK_TEMP in balance_dirty_pages
>
>
>  fs/fuse/dir.c             |   51 ++++
>  fs/fuse/file.c            |  523 +++++++++++++++++++++++++++++++++++++++++----
>  fs/fuse/fuse_i.h          |   20 ++
>  fs/fuse/inode.c           |   98 ++++++++
>  include/uapi/linux/fuse.h |    1
>  mm/page-writeback.c       |    3
>  6 files changed, 638 insertions(+), 58 deletions(-)
>
> --
> Signature
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
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

Re: [fuse-devel] howto share directories (inode, entry) between processes.

[Feng Shuo <steve.shuo.feng@gm...>]

Hi Stef,

IMHO, if notifyfs is a fs just for 'notify', there must be an
under-layer fs to provide the storage. So after the client get the
notification, how about it directly read the content of the dir from
the under-layer fs?

On Wed, Nov 21, 2012 at 2:41 AM, Stef Bon <stefbon@...> wrote:
> Hi,
>
> I'm working on notifyfs, an overlay fs which is also an fs event
> notifier, a database and a cache,
> for clients (gui's wanting to get the contents of a directory).
>
> notifyfs is first an overlay fs, with it's own data of inodes, entrys
> and directory structure.
>
> I'm puzzling about howto get the directory contents from notifyfs to a
> gui client, say
> a patched dolphin filebrowser. I've got something working using a
> socket/fd connection.
> But then, when the client asks (by sending a message to notifyfs)
> notifyfs for the contents of a directory
> by sending the (path, firstname, isdir, maxentries) info. notifyfs
> sends the requested info back. But this
> is slow, since also the client must have a inode/entry tree, and it
> will take time to sync these.
>
> Now I'm thinking aboput sharing the inode/entry/directory data with
> clients. They should first register, and then they can access the
> desired data.
>
> The client can then send a "make sure a directory" (or better: a
> region of a directory) is up to date message, and when this is the
> case, it can read what it requires from the shared memory.
>
> Howto do this best?
>
> I see something like:
>
> http://www.codemaestro.com/reviews/11
>
> This is the way to go?
>
> Thanks in advance,
>
> Stef Bon
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> fuse-devel mailing list
> fuse-devel@...
> 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

Re: [fuse-devel] HSFS v0.2 release

[Feng Shuo <steve.shuo.feng@gm...>]

BTW. I did a quick dd test on my desktop computer:
.........
/dev/fuse           60600040  55391772   2129940  97% /nfs/g
localhost:/nfs/uml  60600040  55391772   2129940  97% /nfs/g
bogon:/nfs/g # dd if=/dev/zero of=test bs=1M count=10K
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 564.701 s, 19.0 MB/s
bogon:/nfs/g # dd of=/dev/zero if=test bs=1M count=10K
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 173.235 s, 62.0 MB/s

The read performance seems good enough with a SATA drive but the write
is poor, I believe it's because of no write cache. I will look into
Maxim's write cache patch and have a try if I get time.

It will be very interesting to see if current write cache mechanism
can support NFS caching mechanism......

On Fri, Nov 23, 2012 at 11:43 AM, Feng Shuo <steve.shuo.feng@...> wrote:
> Hi guys,
>
> The FUSE based NFSv3 client gets a new alpha version now. In this version I
> decouple the fuse_ino_t and nfs3 fileid to support hard link and resolve the
> stale file handle issue.
>
> To do this I steal some Linux kernel codes but at least FUSE framework is
> proved the ability to support NFS or NFS-link file system implementations.
> :-)
>
> The project page is at: https://github.com/openunix/hsfs.
>
> RPMs are also available on openSUSE build service (although I don't think
> there are anybody really want to use it:-). Please refer to the HSFS wiki
> for more details: https://github.com/openunix/hsfs/wiki
>
> Now it is just a nightly build by the Git snapshot. I will do more cleanup
> in codes and then provide the final version of v0.2 release soon.
>
> --
> 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
>



--
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

[fuse-devel] HSFS v0.2 release

[Feng Shuo <steve.shuo.feng@gm...>]

Hi guys,

The FUSE based NFSv3 client gets a new alpha version now. In this version
I decouple the fuse_ino_t and nfs3 fileid to support hard link and resolve
the stale file handle issue.

To do this I steal some Linux kernel codes but at least FUSE framework is
proved the ability to support NFS or NFS-link file system implementations.
:-)

The project page is at: https://github.com/openunix/hsfs.

RPMs are also available on openSUSE build service (although I don't think
there are anybody really want to use it:-). Please refer to the HSFS wiki
for more details: https://github.com/openunix/hsfs/wiki

Now it is just a nightly build by the Git snapshot. I will do more cleanup
in codes and then provide the final version of v0.2 release soon.

-- 
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

Re: [fuse-devel] Flush and returning close(2) errors to userspace

[Han-Wen Nienhuys <hanwenn@gm...>]

On Thu, Nov 22, 2012 at 12:12 PM, Maxim V. Patlasov
<mpatlasov@...> wrote:

>> How should I handle this? Should the FS daemon associate the open file
>> with inode directly, and only issue the close on the last flush()? Or
>> maybe some scheme with reference counting?
>>
>
> I think flush should flush something (e.g. internal FS daemon caches), not
> really close backing store file. One way to trigger flush on backing store
> is close(dup(fd)). Another way would be fsync(fd), imho.

this works for me. I think fsync() may flush the entire filesystem on
many systems, so that's not desired.

-- 
Han-Wen Nienhuys - hanwen@... - http://www.xs4all.nl/~hanwen

Re: [fuse-devel] [PATCH 14/14] mm: Account for WRITEBACK_TEMP in balance_dirty_pages

[Maxim V. Patlasov <mpatlasov@pa...>]

Hi,

11/22/2012 05:27 PM, Jaegeuk Hanse пишет:
> On 11/21/2012 08:01 PM, Maxim Patlasov wrote:
>> Added linux-mm@ to cc:. The patch can stand on it's own.
>>
>>> Make balance_dirty_pages start the throttling when the WRITEBACK_TEMP
>>> counter is high enough. This prevents us from having too many dirty
>>> pages on fuse, thus giving the userspace part of it a chance to write
>>> stuff properly.
>>>
>>> Note, that the existing balance logic is per-bdi, i.e. if the fuse
>>> user task gets stuck in the function this means, that it either
>>> writes to the mountpoint it serves (but it can deadlock even without
>>> the writeback) or it is writing to some _other_ dirty bdi and in the
>>> latter case someone else will free the memory for it.
>> Signed-off-by: Maxim V. Patlasov <MPatlasov@...>
>> Signed-off-by: Pavel Emelyanov <xemul@...>
>> ---
>>   mm/page-writeback.c |    3 ++-
>>   1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
>> index 830893b..499a606 100644
>> --- a/mm/page-writeback.c
>> +++ b/mm/page-writeback.c
>> @@ -1220,7 +1220,8 @@ static void balance_dirty_pages(struct 
>> address_space *mapping,
>>            */
>>           nr_reclaimable = global_page_state(NR_FILE_DIRTY) +
>>                       global_page_state(NR_UNSTABLE_NFS);
>> -        nr_dirty = nr_reclaimable + global_page_state(NR_WRITEBACK);
>> +        nr_dirty = nr_reclaimable + global_page_state(NR_WRITEBACK) +
>> +            global_page_state(NR_WRITEBACK_TEMP);
>
> Could you explain NR_WRITEBACK_TEMP is used for accounting what? And 
> when it will increase?

The only user of NR_WRITEBACK_TEMP is fuse. Handling .writepage it:

1) allocates new page
2) copies original page (that came to .writepage as argument) to new page
3) attaches new page to fuse request
4) increments NR_WRITEBACK_TEMP
5) does end_page_writeback on original page
6) schedules fuse request for processing

Later, fuse request will be send to userspace, then userspace will 
process it and ACK it to kernel fuse. Processing this ACK from 
userspace, in-kernel fuse will free that new page and decrement 
NR_WRITEBACK_TEMP.

So, effectively, NR_WRITEBACK_TEMP keeps track of pages which are under 
'fuse writeback'.

Thanks,
Maxim

>
>> global_dirty_limits(&background_thresh, &dirty_thresh);
>>
>> -- 
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@...  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@..."> email@... </a>
>
>
>

Re: [fuse-devel] [PATCH 14/14] mm: Account for WRITEBACK_TEMP in balance_dirty_pages

[Jaegeuk Hanse <jaegeuk.hanse@gm...>]

On 11/21/2012 08:01 PM, Maxim Patlasov wrote:
> Added linux-mm@ to cc:. The patch can stand on it's own.
>
>> Make balance_dirty_pages start the throttling when the WRITEBACK_TEMP
>> counter is high enough. This prevents us from having too many dirty
>> pages on fuse, thus giving the userspace part of it a chance to write
>> stuff properly.
>>
>> Note, that the existing balance logic is per-bdi, i.e. if the fuse
>> user task gets stuck in the function this means, that it either
>> writes to the mountpoint it serves (but it can deadlock even without
>> the writeback) or it is writing to some _other_ dirty bdi and in the
>> latter case someone else will free the memory for it.
> Signed-off-by: Maxim V. Patlasov <MPatlasov@...>
> Signed-off-by: Pavel Emelyanov <xemul@...>
> ---
>   mm/page-writeback.c |    3 ++-
>   1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index 830893b..499a606 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -1220,7 +1220,8 @@ static void balance_dirty_pages(struct address_space *mapping,
>   		 */
>   		nr_reclaimable = global_page_state(NR_FILE_DIRTY) +
>   					global_page_state(NR_UNSTABLE_NFS);
> -		nr_dirty = nr_reclaimable + global_page_state(NR_WRITEBACK);
> +		nr_dirty = nr_reclaimable + global_page_state(NR_WRITEBACK) +
> +			global_page_state(NR_WRITEBACK_TEMP);
>   

Could you explain NR_WRITEBACK_TEMP is used for accounting what? And 
when it will increase?

>   		global_dirty_limits(&background_thresh, &dirty_thresh);
>   
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@..."> email@... </a>

Re: [fuse-devel] Flush and returning close(2) errors to userspace

[Maxim V. Patlasov <mpatlasov@pa...>]

Hi,

11/22/2012 02:42 PM, Han-Wen Nienhuys пишет:
> Hi there,
>
> when writing a FUSE FS that uses a open file in a backing store to
> correspond to a FUSE opened, how should I treat flush vs. release vs.
> close?
>
> Given that I should return a close(2) error code to the caller, I
> should wire up it up with the FLUSH operation, ie.
>
> func (f *LoopbackFile) Release() {
>    // .. nop.
> }
>
> func (f *LoopbackFile) Flush() Status {
> 	f.lock.Lock()
> 	code := f.File.Close()
> 	f.lock.Unlock()
> 	return code
> }

The way how fusexmp_fh treats flush vs. release:

static int xmp_flush(const char *path, struct fuse_file_info *fi)
{
int res;

(void) path;
/* This is called from every close on an open file, so call the
close on the underlying filesystem. But since flush may be
called multiple times for an open file, this must not really
close the file. This is important if used on a network
filesystem like NFS which flush the data/metadata on close() */
res = close(dup(fi->fh));
if (res == -1)
return -errno;

return 0;
}

static int xmp_release(const char *path, struct fuse_file_info *fi)
{
(void) path;
close(fi->fh);

return 0;
}

Doesn't it fit your needs?

> however, the documentation stresses that I should be prepared for
> receiving multiple flushes on the same fuse file. In that case, the
> second flush would return EBADF since the fd is already closed, which
> would confuse the caller.
>
> How should I handle this? Should the FS daemon associate the open file
> with inode directly, and only issue the close on the last flush()? Or
> maybe some scheme with reference counting?
>

I think flush should flush something (e.g. internal FS daemon caches), 
not really close backing store file. One way to trigger flush on backing 
store is close(dup(fd)). Another way would be fsync(fd), imho.

Thanks,
Maxim

[fuse-devel] Flush and returning close(2) errors to userspace

[Han-Wen Nienhuys <hanwenn@gm...>]

Hi there,

when writing a FUSE FS that uses a open file in a backing store to
correspond to a FUSE opened, how should I treat flush vs. release vs.
close?

Given that I should return a close(2) error code to the caller, I
should wire up it up with the FLUSH operation, ie.

func (f *LoopbackFile) Release() {
  // .. nop.
}

func (f *LoopbackFile) Flush() Status {
	f.lock.Lock()
	code := f.File.Close()
	f.lock.Unlock()
	return code
}

however, the documentation stresses that I should be prepared for
receiving multiple flushes on the same fuse file. In that case, the
second flush would return EBADF since the fd is already closed, which
would confuse the caller.

How should I handle this? Should the FS daemon associate the open file
with inode directly, and only issue the close on the last flush()? Or
maybe some scheme with reference counting?

-- 
Han-Wen Nienhuys - hanwen@... - http://www.xs4all.nl/~hanwen

Re: [fuse-devel] howto share directories (inode, entry) between processes.

[Stef Bon <stefbon@gm...>]

Hi,

anyone an idea?

I have to wrote a "shared memory allocater" myself. Anyone a suggestion?

Stef

[fuse-devel] [PATCH v4 04/31] fuse: convert fuse to use iov_iter_copy_[to|from]_user

[Dave Kleikamp <dave.kleikamp@or...>]

A future patch hides the internals of struct iov_iter, so fuse should
be using the supported interface.

Signed-off-by: Dave Kleikamp <dave.kleikamp@...>
Acked-by: Miklos Szeredi <mszeredi@...>
Cc: fuse-devel@...
---
 fs/fuse/file.c | 29 ++++++++---------------------
 1 file changed, 8 insertions(+), 21 deletions(-)

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 78d2837..4e42e95 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -1631,30 +1631,17 @@ static int fuse_ioctl_copy_user(struct page **pages, struct iovec *iov,
 	while (iov_iter_count(&ii)) {
 		struct page *page = pages[page_idx++];
 		size_t todo = min_t(size_t, PAGE_SIZE, iov_iter_count(&ii));
-		void *kaddr;
+		size_t left;
 
-		kaddr = kmap(page);
-
-		while (todo) {
-			char __user *uaddr = ii.iov->iov_base + ii.iov_offset;
-			size_t iov_len = ii.iov->iov_len - ii.iov_offset;
-			size_t copy = min(todo, iov_len);
-			size_t left;
-
-			if (!to_user)
-				left = copy_from_user(kaddr, uaddr, copy);
-			else
-				left = copy_to_user(uaddr, kaddr, copy);
-
-			if (unlikely(left))
-				return -EFAULT;
+		if (!to_user)
+			left = iov_iter_copy_from_user(page, &ii, 0, todo);
+		else
+			left = iov_iter_copy_to_user(page, &ii, 0, todo);
 
-			iov_iter_advance(&ii, copy);
-			todo -= copy;
-			kaddr += copy;
-		}
+		if (unlikely(left))
+			return -EFAULT;
 
-		kunmap(page);
+		iov_iter_advance(&ii, todo);
 	}
 
 	return 0;
-- 
1.8.0

Re: [fuse-devel] [PATCH 14/14] mm: Account for WRITEBACK_TEMP in balance_dirty_pages

[Maxim Patlasov <mpatlasov@pa...>]

Added linux-mm@ to cc:. The patch can stand on it's own.

> Make balance_dirty_pages start the throttling when the WRITEBACK_TEMP
> counter is high enough. This prevents us from having too many dirty
> pages on fuse, thus giving the userspace part of it a chance to write
> stuff properly.
> 
> Note, that the existing balance logic is per-bdi, i.e. if the fuse
> user task gets stuck in the function this means, that it either
> writes to the mountpoint it serves (but it can deadlock even without
> the writeback) or it is writing to some _other_ dirty bdi and in the
> latter case someone else will free the memory for it.

Signed-off-by: Maxim V. Patlasov <MPatlasov@...>
Signed-off-by: Pavel Emelyanov <xemul@...>
---
 mm/page-writeback.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 830893b..499a606 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1220,7 +1220,8 @@ static void balance_dirty_pages(struct address_space *mapping,
 		 */
 		nr_reclaimable = global_page_state(NR_FILE_DIRTY) +
 					global_page_state(NR_UNSTABLE_NFS);
-		nr_dirty = nr_reclaimable + global_page_state(NR_WRITEBACK);
+		nr_dirty = nr_reclaimable + global_page_state(NR_WRITEBACK) +
+			global_page_state(NR_WRITEBACK_TEMP);
 
 		global_dirty_limits(&background_thresh, &dirty_thresh);
 

[fuse-devel] howto share directories (inode, entry) between processes.

[Stef Bon <stefbon@gm...>]

Hi,

I'm working on notifyfs, an overlay fs which is also an fs event
notifier, a database and a cache,
for clients (gui's wanting to get the contents of a directory).

notifyfs is first an overlay fs, with it's own data of inodes, entrys
and directory structure.

I'm puzzling about howto get the directory contents from notifyfs to a
gui client, say
a patched dolphin filebrowser. I've got something working using a
socket/fd connection.
But then, when the client asks (by sending a message to notifyfs)
notifyfs for the contents of a directory
by sending the (path, firstname, isdir, maxentries) info. notifyfs
sends the requested info back. But this
is slow, since also the client must have a inode/entry tree, and it
will take time to sync these.

Now I'm thinking aboput sharing the inode/entry/directory data with
clients. They should first register, and then they can access the
desired data.

The client can then send a "make sure a directory" (or better: a
region of a directory) is up to date message, and when this is the
case, it can read what it requires from the shared memory.

Howto do this best?

I see something like:

http://www.codemaestro.com/reviews/11

This is the way to go?

Thanks in advance,

Stef Bon