#10 Support nano-second file timestamps

[Marc Siegel]

Hi UNFS3 team,

First off, a big thank you, and a round of applause from all the users of UNFS3 over the years. Great work!

Now, unfortunately it's time to look for a "proof of life" of this project. I notice patches and issues sitting unremarked for years.

Can you please respond to this issue if this project is alive?

If no response in one week, as a community we can regard this project as dead, and start looking for a new upstream.

Thanks!
-Marc

[Marc Siegel]

See also: https://github.com/codekitchen/dinghy/issues/269#issuecomment-381701748

[Karl Mikaelsson]

Hi there,

unfs3 hasn't received much time and effort from myself and others over the last years, and while I really like to say that the maintainers (at least us from Cendio AB) have every intention to be facilitators for great, vibrant, open source projects. Then again, intentions are worthless - actions count. I can't refute your comments about patches and issues rotting in SourceForge. If that's your measure of dead, then I guess we're dead. :)

If you or someone on your team is willing to contribute a fix for nano-second timestamp resolutions, that would be most welcome.

[Marc Siegel]

Thanks @karl. Sounds like it would be to say that this project is only mostly dead, then?

Please let us know : our cursory understanding is that UNFS3 already supports nanosecond timestamps, and that the required fix would be to add support for this on APFS on Mac OS High Sierra only. We imagined that this would be taking the bits from other projects (such as go-lang) that added this support, and weaving them into the appriopriate places in UNFS3.

Are these assumptions correct? Is it true that UNFS3 supports nanosecond timestamps in general, and just needs the support for High Sierra added?

[Marc Siegel]

And secondly: If we were to develop a patch, how would we go about submitting it?

Our extreme preference would be to develop as a Github pull request against the mirror repo there, as that is a workflow everyone is comfortable with and the development would be very public.

If you don't control that repo, our second preference would be to create our own mirror on Github, and do the same there.

But if the requirement is to email patches or whatever, I don't think there's any chance.

[Karl Mikaelsson]

Feel free to submit pull requests against https://github.com/unfs3/unfs3

[Karl Mikaelsson]

To address the technical issues here, the NFS protocol supports nanosecond resolution timestamps. The issue with unfsd seems to be that the integration with the OS uses utime, which supports a resolution of seconds. There are other API:s (utimes, utimensat) which supports higher resolution timestamps (microseconds/nanoseconds).

This looks to be an issue on all platforms, and not just macOS or High Sierra in particular. I've made a prototype of a fix on a branch over at github. I haven't really done anything other than verify that it compiles on macOS, so don't blame me if it doesn't build or if it crashes :)

[Marc Siegel]

Thanks so much @derfian ! I've built your branch from github on Mac OS High Sierra and can verify that it at least compiles and runs. Please note: I am posting here because Issues are not enabled on your GitHub repo.

Unfortunately, I've verified that when your branch of the unfs3 server is running on the Mac OS host, when a Ubuntu Linux client mounts the directory, it reports the nanosecond timestamps as still being all zero.

For example, inside a Ubuntu container that has mounted the UNFS3 share in /app:

root@9dea09b6337a:/app# touch a && touch b && ls --full-time a b
-rw-r--r-- 1 501 dialout 0 2018-05-09 16:06:01.000000000 +0000 a
-rw-r--r-- 1 501 dialout 0 2018-05-09 16:06:01.000000000 +0000 b

But there is progress! I think your patch has fixed setting the time, as you can observe the following mtime in nanoseconds on the Mac OS server host:

# using GNU ls from `brew install coreutils` to see nanoseconds
$ gls -la --full-time a b
-rw-r--r-- 1 marcsiegel staff 0 2018-05-09 12:06:01.632695000 -0400 a
-rw-r--r-- 1 marcsiegel staff 0 2018-05-09 12:06:01.637569000 -0400 b

Therefore, my hypothesis is:

1. Your branch has successfully implemented setting nanosecond mtime
2. We still need to read the nanosecond timestamps and report via NFS

After reviewing the code, could it be as simple as editing attr.c in the functions get_pre_cached and get_post_buf to set the nanosecond fields from the backend_statstruct buf instead of setting to literal 0 values?

Or, is it necessary to also add #ifdef blocks in the place where the stat call is made?

[Karl Mikaelsson]

I've pushed more commits to my branch, give it a try. I haven't really tested much, so it's the same as before. I'm mostly concerned with writing portable code. I don't think clock_gettime and struct timespec will be available on older platforms.

[Marc Siegel]

Thanks @derfian.

On Mac OS High Sierra, I get a build failure:

==> make
for i in Config ; do (cd $i && make all) || exit; done
flex ./exports.l
bison -y -d ./exports.y
clang -g -O2 -Wall -W -I.. -I. -I..   -c -o lex.yy.o lex.yy.c
clang -g -O2 -Wall -W -I.. -I. -I..   -c -o y.tab.o y.tab.c
ar crs lib.a lex.yy.o y.tab.o
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o afsgettimes.o afsgettimes.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o afssupport.o afssupport.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o attr.o attr.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o daemon.o daemon.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o error.o error.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o fd_cache.o fd_cache.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o fh.o fh.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o fh_cache.o fh_cache.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o locate.o locate.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o md5.o md5.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o mount.o mount.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o nfs.o nfs.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o password.o password.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o readdir.o readdir.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o user.o user.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o xdr.o xdr.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o winsupport.o winsupport.c
clang -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o clock_gettime.o clock_gettime.c
In file included from clock_gettime.c:4:
./clock_gettime.h:14:5: error: conflicting types for 'clock_gettime'
int clock_gettime(int clock, struct timespec *timespec);
    ^
/usr/include/time.h:177:5: note: previous declaration is here
int clock_gettime(clockid_t __clock_id, struct timespec *__tp);
    ^
clock_gettime.c:11:5: error: conflicting types for 'clock_gettime'
int clock_gettime(int clock, struct timespec *timespec) {
    ^
/usr/include/time.h:177:5: note: previous declaration is here
int clock_gettime(clockid_t __clock_id, struct timespec *__tp);
    ^
2 errors generated.
make: *** [clock_gettime.o] Error 1
/usr/local/Homebrew/Library/Homebrew/debrew.rb:11:in `raise'
BuildError: Failed executing: make

1. raise
2. ignore
3. backtrace
4. irb
5. shell

[Marc Siegel]

@derfian, perhaps I am missing something, but it seems likely to me that we're simply missing at the top of clock_gettime.c the regular old:

#include "config.h"

I ask because I noticed that

1. Autoconf is detecting the presence of clock_gettime and therefore config.h is generated containing #define HAVE_CLOCK_GETTIME 1
2. clock_gettime.c is checking #ifndef HAVE_CLOCK_GETTIME, but this will always fail because it doesn't #include "config.h"

Does the above make sense? Apologies of this is way off.

[Karl Mikaelsson]

Yep, that's it. I've pushed a new commit for this problem, thanks for letting me know.

[Marc Siegel]

Hurray! @derfian I've verified your fix! :)

I have verifed by running Dinghy on Mac OS High Sierra (10.13.4). In order to verify your fix, I had to kill the fsevents_to_vm part of Dinghy, as that appears to have a separate issue with it. This leaves us with a Linux VM running in VirtualBox with boot2docker running inside, and mounting my home directory via your branch of unfs3.

A. On Mac OS, run Dinghy with your branch of unfs3:

# switch to my branch of homebrew-dinghy to use your branch of unfs3
cd $(brew --repository codekitchen/dinghy)
git remote add ms-ati https://github.com/ms-ati/homebrew-dinghy.git
git checkout use-unfs3-branch-higher-resolution-setattr

# from there, force install your branch of unfs3
brew uninstall --ignore-dependencies unfs3
brew install --build-from-source --devel --verbose --debug unfs3

# run Dinghy, but kill the fsevents_to_vm parts
dinghy down
dinghy up
killall fsevent_watch
killall fsevents_to_vm

# run a Docker container mounting my Mac home dir over unfs3
docker-compose run -it my-app bash

B. Touch and stat file on the host Mac OS

$ brew install coreutils # for gls
$ touch a b && gls --full-time a b
-rw-r--r-- 1 marcsiegel staff 0 2018-05-16 09:49:11.759413000 -0400 a
-rw-r--r-- 1 marcsiegel staff 0 2018-05-16 09:49:11.759413000 -0400 b

C. Stat and touch and stat file inside container Ubuntu

root@ed780020e164:/app# ls --full-time a b
-rw-r--r-- 1 501 dialout 0 2018-05-16 13:49:11.759413000 +0000 a
-rw-r--r-- 1 501 dialout 0 2018-05-16 13:49:11.759413000 +0000 b

root@ed780020e164:/app# touch a b && ls --full-time a b
-rw-r--r-- 1 501 dialout 0 2018-05-16 13:49:45.428323000 +0000 a
-rw-r--r-- 1 501 dialout 0 2018-05-16 13:49:45.429498000 +0000 b

D. Stat files again on the host Mac OS

$ gls --full-time a b
-rw-r--r-- 1 marcsiegel staff 0 2018-05-16 09:49:45.428323000 -0400 a
-rw-r--r-- 1 marcsiegel staff 0 2018-05-16 09:49:45.429498000 -0400 b

[Marc Siegel]

Since the nanosecond timestamps now work on your branch -- what is the process to make a release that includes this code?

[Marc Siegel]

Hi @derfian, ping on making a release ?

[Karl Mikaelsson]

I have a few portability concerns about the new code that I'd like to review before merging to master. Making a new release isn't at the top of my priority list at the moment.

[Marc Siegel]

No worries, I understand. In the meantime, would you be willing to commit to keeping your existing Github branch available at the same path? Could we temporarily make dinghy depend on that branch to build, to get Mac OS docker users back into good shape, and later change the dependency to be your next release?

[Karl Mikaelsson]

Sure, I will do that. I don't mind having the dinghy team depend on this branch until everything else settles into place.

[Marc Siegel]

+1 sounds good @derfian

For reference, here's a PR to homebrew-dinghy to change the UNFS3 dependency to your branch:
https://github.com/codekitchen/homebrew-dinghy/pull/2