[9fans] Linux 9p timestamps

[9fans] Linux 9p timestamps

[csant]

Hola,

mounting a Plan 9 machine with
	# mount -t 9p -o proto=tcp 10.0.0.5 /mnt/9/
on a Linux box with a vanilla kernel 2.6.17.7

On the Plan 9 machine:
	% ls -l tmp/file
	--rw-rw-r-- M 8 csant csant 1188 Jul 30 07:06 tmp/file
and on the Linux machine:
	$ ls -l /mnt/9/usr/csant/tmp/file
	-rw-rw-r--  1 root root 1188 2006-07-30 13:06 /mnt/9/usr/csant/tmp/file

Note that on both machines `date` gives the same, correct time. Why does  
the 9p mount give me a different time?
/c

[9fans] Re: Linux 9p timestamps

[Eric Van Hensbergen]

On 7/30/06, csant <csant@csant.info> wrote:
> Hola,
>
> mounting a Plan 9 machine with
>         # mount -t 9p -o proto=tcp 10.0.0.5 /mnt/9/
> on a Linux box with a vanilla kernel 2.6.17.7
>
> On the Plan 9 machine:
>         % ls -l tmp/file
>         --rw-rw-r-- M 8 csant csant 1188 Jul 30 07:06 tmp/file
> and on the Linux machine:
>         $ ls -l /mnt/9/usr/csant/tmp/file
>         -rw-rw-r--  1 root root 1188 2006-07-30 13:06 /mnt/9/usr/csant/tmp/file
>
> Note that on both machines `date` gives the same, correct time. Why does
> the 9p mount give me a different time?
>

Bizarre, never noticed that before -- there is no such anomoly with
the UNIX based server (npfs anyways).   Looking at the stat(5) man
page, looks like 9p is supposed to deliver mtime and atime in terms of
GMT. It would then be the responsibility of the client to adjust for
his/her local time zone.  I don't believe we are doing that at the
moment.  I'll add it to the bug list.  Thanks.

          -eric

Re: [9fans] Re: Linux 9p timestamps

[C H Forsyth]

>It would then be the responsibility of the client to adjust for
>his/her local time zone.

isn't the value of ctime and mtime always in gmt, even on linux?
on unix it was only the programs calling ctime (or relatives)
that finally adjusted for local time, typically before displaying it.
i don't see how the client kernel would or should get involved.

Re: [9fans] Re: Linux 9p timestamps

[erik quanstrom]

yes.  unix and plan 9 both use seconds since epoch to
represent the date and both use an epoch defined in the
GMT timezone.

there shouldn't be any conversion required as the timezone+dst
offset needs to be added only for display.

- erik

On Sun Jul 30 14:51:52 CDT 2006, forsyth@vitanuova.com wrote:
> >It would then be the responsibility of the client to adjust for
> >his/her local time zone.
>
> isn't the value of ctime and mtime always in gmt, even on linux?
> on unix it was only the programs calling ctime (or relatives)
> that finally adjusted for local time, typically before displaying it.
> i don't see how the client kernel would or should get involved.

Re: [9fans] Re: Linux 9p timestamps

[Eric Van Hensbergen]

On 7/30/06, erik quanstrom <quanstro@quanstro.net> wrote:
> yes.  unix and plan 9 both use seconds since epoch to
> represent the date and both use an epoch defined in the
> GMT timezone.
>
> there shouldn't be any conversion required as the timezone+dst
> offset needs to be added only for display.
>
> - erik
>
> On Sun Jul 30 14:51:52 CDT 2006, forsyth@vitanuova.com wrote:
> > >It would then be the responsibility of the client to adjust for
> > >his/her local time zone.
> >
> > isn't the value of ctime and mtime always in gmt, even on linux?
> > on unix it was only the programs calling ctime (or relatives)
> > that finally adjusted for local time, typically before displaying it.
> > i don't see how the client kernel would or should get involved.
>

okay - I'll bite -- so what's csant's problem then?

          -eric

Re: [9fans] Re: Linux 9p timestamps

[Steve Simon]

> okay - I'll bite -- so what's csant's problem then?

Timezone tables being trash at one end or the other?

How about 10 lines of C to print stat()'s mtime of the
shared file in decimal from both plan9's point of view
and Unix's?

-Steve

Re: [9fans] Re: Linux 9p timestamps

[erik quanstrom]

how about
	timezone=GMT date 	# plan 9
and
	date --utc		# linux

if these, differ, you need to take a look at timezones.
then
	syscall -s fstat 0 buf 1024 	< $file	# plan 9
and
	stat $file				# unix
if these differ, maybe v9fs is doing some extra conversion?

- erik

On Mon Jul 31 02:28:46 CDT 2006, steve@quintile.net wrote:
> > okay - I'll bite -- so what's csant's problem then?
>
> Timezone tables being trash at one end or the other?
>
> How about 10 lines of C to print stat()'s mtime of the
> shared file in decimal from both plan9's point of view
> and Unix's?
>
> -Steve

Re: [9fans] Re: Linux 9p timestamps

[Lluís Batlle]

I don't know if you take that into account, but I think GMT and UTC
are different zones.

GMT is UTC+1 at summer.

(I'm not sure if that's true or not, I got that from an Internet web
page: http://www.timeanddate.com/worldclock/ )

2006/7/31, erik quanstrom <quanstro@quanstro.net>:
> how about
>         timezone=GMT date       # plan 9
> and
>         date --utc              # linux
>
> if these, differ, you need to take a look at timezones.
> then
>         syscall -s fstat 0 buf 1024     < $file # plan 9
> and
>         stat $file                              # unix
> if these differ, maybe v9fs is doing some extra conversion?
>
> - erik
>
> On Mon Jul 31 02:28:46 CDT 2006, steve@quintile.net wrote:
> > > okay - I'll bite -- so what's csant's problem then?
> >
> > Timezone tables being trash at one end or the other?
> >
> > How about 10 lines of C to print stat()'s mtime of the
> > shared file in decimal from both plan9's point of view
> > and Unix's?
> >
> > -Steve
>

Re: [9fans] Re: Linux 9p timestamps

[csant]

>> how about
>>         timezone=GMT date       # plan 9
	Tue Aug 1 01:33:05 GMT 2006

>> and
>>         date --utc              # linux
	Mon Jul 31 19:33:18 UTC 2006

However, just running `date` on both machines returns the correct values.

>> if these, differ, you need to take a look at timezones.

	% cat /env/timezone
	EST -18000 EDT -14400

Is there something I need to fix?

>> then
>>         syscall -s fstat 0 buf 1024     < $file # plan 9

	[csant] (0000000000003e7f 2 00) --rw-rw-r-- (664) M 8 csant csant 213 Jul  
31 00:51 guide
	        mtime: Mon Jul 31 00:51:12 EDT 2006 (1154321472)
	        atime: Mon Jul 31 20:50:03 EDT 2006 (1154393403)

>> and
>>         stat $file                              # unix

	  File: `/mnt/9/usr/csant/guide'
	  Size: 213             Blocks: 1          IO Block: 16384  regular file
	Device: 12h/18d Inode: 16001       Links: 1
	Access: (0664/-rw-rw-r--)  Uid: (    0/    root)   Gid: (    0/    root)
	Access: 2006-08-01 02:50:03.282078625 +0200
	Modify: 2006-07-31 06:51:12.282078625 +0200
	Change: 2006-07-31 06:51:12.282078625 +0200

/c

Re: [9fans] Re: Linux 9p timestamps

[Steve Simon]

It depends where in the world you are (which timezone).

felix% grep 'EST -18000 EDT -14400' /adm/timezone/*
/adm/timezone/Canada_Eastern:EST -18000 EDT -14400
/adm/timezone/Jamaica:EST -18000 EDT -14400
/adm/timezone/US_East-Indiana:EST -18000 EDT -14400
/adm/timezone/US_Eastern:EST -18000 EDT -14400
/adm/timezone/US_Michigan:EST -18000 EDT -14400

Your timezone is correct for the eastern Americas,
however your domain is registered in Italy, perhaps you
are there?

If so I think you need to do somthing like:
	cp /adm/timezone/CET /adm/timezone/local
and reboot.

Your clock will then be wrong and
need to be reset, this should synchronise things,
or perhaps I have the wrong end of the stick completely.

-Steve

Re: [9fans] Re: Linux 9p timestamps

[csant]

> It depends where in the world you are (which timezone).
>
> felix% grep 'EST -18000 EDT -14400' /adm/timezone/*
> /adm/timezone/Canada_Eastern:EST -18000 EDT -14400
> /adm/timezone/Jamaica:EST -18000 EDT -14400
> /adm/timezone/US_East-Indiana:EST -18000 EDT -14400
> /adm/timezone/US_Eastern:EST -18000 EDT -14400
> /adm/timezone/US_Michigan:EST -18000 EDT -14400
>
> Your timezone is correct for the eastern Americas,
> however your domain is registered in Italy, perhaps you
> are there?

I am in Norway - and obviously still a n00b :)

> If so I think you need to do somthing like:
> 	cp /adm/timezone/CET /adm/timezone/local
> and reboot.

Done, thanks.

> Your clock will then be wrong and
> need to be reset, this should synchronise things,
> or perhaps I have the wrong end of the stick completely.

I guess the end of the stick is right - and so was my clock as well, after
reboot. Creation time of my files is a bit off now, but that doesn't
really matter atm - but at least my Linux and my Plan 9 machines report
the same timestamp, now. Sorry for the confusion.

/c (learning new bits and pieces every day)

Re: [9fans] Re: Linux 9p timestamps

[erik quanstrom]

you're not the first to make this mistake.

- erik

On Mon Jul 31 17:04:52 CDT 2006, csant@csant.info wrote:
> I guess the end of the stick is right - and so was my clock as well, after
> reboot. Creation time of my files is a bit off now, but that doesn't
> really matter atm - but at least my Linux and my Plan 9 machines report
> the same timestamp, now. Sorry for the confusion.
>
> /c (learning new bits and pieces every day)

Re: [9fans] Re: Linux 9p timestamps

[csant]

> you're not the first to make this mistake.
Duly added a note to the Tip o' the day. I would have liked to create a
new page on the wiki to link to as an additional step to perform after
Installation, Creating a new user and Configuring the network - but how
does one create a new, non-existing page?

/c

Re: Re: [9fans] Re: Linux 9p timestamps

[Anthony Sorace]

// GMT is UTC+1 at summer.

you misread the note on that page. UTC and GMT are the same, modulo
leap seconds. GB is currently on British Summer Time, not GMT, and is
one hour ahead of that.