Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!psinntp!psinntp!psinntp!spunky.RedBrick.COM!nntp.et.byu.edu!news.byu.edu!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Date: 23 Feb 1996 22:26:00 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 61
Message-ID: <4gleto$8b@park.uvsc.edu>
References: <4ggc9k$kbv@park.uvsc.edu> <4ggj2f$mej@park.uvsc.edu> <4ggo5v$mon@park.uvsc.edu> <4gic4k$6rt@park.uvsc.edu> <4giku8$7k8@park.uvsc.edu> <4giqhh$a9d@park.uvsc.edu> <Dn8ECA.468.0.-s@cs.vu.nl>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14952 comp.os.linux.development.system:18753
kjb@cs.vu.nl (Kees J Bot) wrote:
] >After some offline prompting, I checked the code path for an
] >unlink, and it looks like FreeBSD doesn't do the change time
] >update on the directory inode synchronously.
]
] >I think this is probably in violation of POSIX semantic
] >requirements (else why make the distinction in the standard
] >between "shall be updated" and "shall be marked for update"?).
] >Nevertheless, the extra overhead I described is apparently
] >limited to the SVR4 UFS implementation.
]
] Under Minix "shall be marked for update" is done by setting a bit in the
] in-core inode telling that one of [amc]time must be updated somewhere in
] the future. "Shall be updated" is done by actually writing the current
] time into one of [amc]time that has been marked for update.
]
] Why? Because getting the current time is an expensive call from the file
] server to the clock task. The last close of a file, one of the stat()
] calls or a sync() triggers the time update. He who wrote this code
] assumed that this is what POSIX meant by "shall be marked for update",
] i.e. getting the time may be expensive, so you can delay it until "shall
] be updated".
After consultation with the 88 and 90 POSIX standards and Matt
Day, I agree that POSIX can be interpreted as not requiring a
commit to stable storage when it says "shall be updated".
The interpretation Matt proposes is similar to that you state
for Minix: "shall be marked for update" means that the system
clock must be read at some future time, and "shall be updated"
means that the clock has to be read now, as opposed to setting
marking flags.
In addition, in the rationale, it looks like the system clock
may be decoupled from the hardware clock. This is what SVR4
does that eventually results in them not complying with SVID III
for the RT functions getitimer/setitimer/gettimeofday/select,
but does not affect POSIX compliance.
The net effect is that the only place in FreeBSD that is not
as lax as POSIX allows is the VOP_SETATTR, which synchronously
writes its changes when it technically does not need to.
I was deluded by some requirements for a previous project that
were attributed to POSIX; specifically, in the stat/fstat/close
case, the "shall be updated" was interpreted as requiring a
write at close time. The project was a NetWare file server,
where a SearchContinue NCP would result in an open, a getdirents
(readdir) type call, and then a close (DOS does not require
that searched be terminated).
Sorry for the resulting confusion.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.