[Libguestfs] [PATCH 5/5 v3] fuse: Add tests for guestmount.

[Matthew Booth]

On 11/18/2009 10:23 AM, Richard W.M. Jones wrote:
> On Wed, Nov 18, 2009 at 09:44:10AM +0000, Matthew Booth wrote:
>>> +stage Checking file modes of initial content
>>> +[ "$(stat -c %a empty)" = "644" ]
>>> +[ "$(stat -c %a hello.txt)" = "644" ]
>>> +[ "$(stat -c %a world.txt)" = "644" ]
>>
>> You need to explicitly set the umask to 022 at the beginning of the
>> script for this to be reliable.
>
> libguestfs guarantees the initial umask already:
>
> http://libguestfs.org/guestfs.3.html#guestfs_umask
> http://git.annexia.org/?p=libguestfs.git;a=blob;f=daemon/guestfsd.c;h=db0bff926de99cb89d4003e6c5ed3c9a9917aa42;hb=HEAD#l168

The relevant umask is surely the umask of the user running the test. 
However, given that the tests pass and my umask is 002, I guess it's not 
passing this umask through to the daemon. That's a bug.

>>> +stage Checking sizes of initial content
>>> +[ "$(stat -c %s empty)" -eq 0 ]
>>> +[ "$(stat -c %s hello.txt)" -eq 5 ]
>>> +[ "$(stat -c %s world.txt)" -eq 11 ]
>>
>> While you're at it, you could add tests for every other stat field.
>
> Yup, I've checked most of them, but more would be better.
>
>>> +# This fails because of caching.  The problem is that the linked file
>>> +# ("hello.txt") is cached with a link count of 2.  unlink("link")
>>> +# invalidates the cache for "link", but_not_  for "hello.txt" which
>>> +# still has the now-incorrect cached value.  However there's not much
>>> +# we can do about this since searching for all linked inodes of a file
>>> +# is an O(n) operation.
>>> +#[ "$(stat -c %h hello.txt)" -eq 1 ]
>>
>> Eurgh. What's the impact of not caching?
>
> It's really really slow.
>
> Note that the problem here is fairly minor.  You'll see a link count
> of 2 instead of 1 for just a few seconds.
>
>> Alternatively, inotify can spot an updated link count. What's the
>> potential for adding asynchronous cache invalidation from the daemon?
>
> I don't think inotify helps here ...  The linked file could be
> anywhere in the whole filesystem, so you'd have to have inotify
> watches in every single directory in the filesystem.

Actually I was thinking inotify in the daemon when a file is cached, 
dropped when dropped by the client, with an explicit notification to the 
client when invalidated on the daemon side.

However, that's a rather large hammer for a small nut. I'll let it pass ;)

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490