Re: [PATCH v12 resend] fs: Add VirtualBox guest shared folder (vboxsf) support

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 12-08-19 16:17, Christoph Hellwig wrote:

<snip>

>> The problem is that the IPC to the host which we build upon only offers
>> regular read / write calls. So the most consistent (also cache coherent)
>> mapping which we can offer is to directly mapping read -> read and
>> wrtie->write without the pagecache. Ideally we would be able to just
>> say sorry cannot do mmap, but too much apps rely on mmap and the
>> out of tree driver has this mmap "emulation" which means not offering
>> it in the mainline version would be a serious regression.
>>
>> In essence this is the same situation as a bunch of network filesystems
>> are in and I've looked at several for inspiration. Looking again at
>> e.g. v9fs_file_write_iter it does similar regular read -> read mapping
>> with invalidation of the page-cache for mmap users.
> 
> v9 is probably not a good idea to copy in general.  While not the best
> idea to copy directly either I'd rather look at nfs - that is another
> protocol without a real distributed lock manager, but at least the
> NFS close to open semantics are reasonably well defined and allow using
> the pagecache.

Ok, I've been taking a quick peek at always using the page-cache for
writes, like NFS is doing.

One scenario here which I still have questions about is normal write
syscalls on a file opened in append mode. Currently I'm relying on
passing through the append flag to the host while opening the file.

This is fine for address_space_operations.write_end which AFAICT will be used
in case of implementing the write_iter callback through generic_perform_write,
this is fine for write_end since in write_end I have access to file->private_data
and thus to the IPC handle representing the open call with the append flag set,
so I do not need to worry about the host having changed the file underneath
us, since the host will make sure the write gets appended itself.

But what about address_space_operations.writepage? I guess this will never
get called as the result of a write call on a file with the append flag set,
right ?  So I should have at least one handle around in the list of open
handles for the inode, which does not have the append flag set, so which I
can safely use to writeback dirty pages coming in through writepage(), right ?

Hmm, looking at my current vboxsf writepage code I see that I already only allow
using handles which were opened without the append flag, so I'm pretty sure
that I got this right, still if you can confirm that I've got this right,
that would be great.

And mmap of a file with the append flag set is not supported, so we should
be good there.

Regards,

Hans