[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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:


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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]