Re: [fuse-devel] Linux FUSE handling of utimensat(..., ..., NULL, ...)

[Jean-Pierre A. <jea...@wa...>]

Hi,

Derrik Pates wrote:
> List:
>
> In the process of hacking the Perl fuse bindings to support high-resolution
> timestamps, I noticed something of interest.
>
> In the Linux kernel, the utimensat() syscall is responsible for setting
> timestamps on files explicitly. When a tool like touch operates on a file
> normally, the utimensat() syscall is fed a NULL argument for the times
> parameter (parameter #3 from utimensat(2)). If I do this on a file (or to
> create a file) on a conventional filesystem (say, ext3/4), the file's
> timestamps from stat(2) or the stat CLI tool have a nanosecond portion.
> However, in testing some changes to the Perl fuse wrapper's utimens()
> implementation, I discovered that when I do this on a FUSE filesystem
> implementation, the values fed into the utimens() wrapper consistently have
> no subsecond portion at all (that is to say, the value is consistently 0).
>    

I do not experiment this behavior with ntfs-3g (which is
fuse based, and has a 100 ns timestamp resolution)

[linux@pavilion2 doc]$ touch sample
[linux@pavilion2 doc]$ stat sample
   File: `sample'
   Size: 0               Blocks: 0          IO Block: 4096   regular 
empty file
Device: 803h/2051d      Inode: 817         Links: 1
Access: (0644/-rw-r--r--)  Uid: (  500/   linux)   Gid: (  500/   linux)
Access: 2012-03-09 08:25:03.313673000 +0100
Modify: 2012-03-09 08:25:03.313673000 +0100
Change: 2012-03-09 08:25:03.313673000 +0100
  Birth: -

> However, if I use the "-r" switch to the touch command, to use another
> file's timestamp as a reference for updating the indicated file, my debug
> output shows that the subsecond portion of the times is non-zero.
>
> After some further research, it seems that the responsible function is
> current_fs_time() (in kernel/time.c), which uses the fs->s_time_gran
> attribute to determine the minimum filesystem time granularity. I believe
> the default is assigned in alloc_super() in fs/super.c, and because the
> FUSE kernel module never overrides it (the default is,
> unsurprisingly, 1000000000, and this value is apparently in nanoseconds),
> even if the FUSE implementation on the userspace side of libfuse supports
> it, normally timestamp resolution will be limited to one second. Is there a
> reason this is so? Is there a good reason not to just set fs->s_time_gran
> to 1 and let userspace do the right thing(tm)? If the filesystem only
> implements utime(), the subsecond portion will always be ignored; if it
> implements utimens(), it can round off appropriately as needed. Otherwise I
> think this would require a change to the ABI, to provide a way for the
> implementation to tell the fuse driver what its time resolution should be,
> which is probably more trouble than it's worth for this purpose.
>    

Is that not governed by the "flag_utime_omit_ok" flag
in the fuse init parameters ?

And a side question : I see that stat(1) has a provision
for showing the birth date of a file. Is there a way to
return such a stamp through fuse ?

Jean-Pierre André