Date: Tue, 3 Jan 95 13:35:25 MST From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, crtb@upcoming.dcrt.nih.gov, freebsd-bugs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Why does ls report wrong creation date on symlinks? Message-ID: <9501032035.AA06262@cs.weber.edu> In-Reply-To: <199501031811.FAA10158@godzilla.zeta.org.au> from "Bruce Evans" at Jan 4, 95 05:11:29 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >I don't think it is optional, but one can argue that directories are > >not files, in which case it's non-optional for files but implementation > >defined for directories. > > If they are not files then it would be hard to read the timestamps on > them set by creat() etc. Perhaps they only have to be files on > writable file systems :-). 8-). ...Naw, the VMS guys would never go for it. > >I personally used the non-file directory interpretation to implement > >a promiscuous lookup mechanism. Because it used ioctl's, it did not > >fall under the requirements of the readdir interface, even though it > >returned additional per file meta data as well as ordering in a > >directory along with the entries. A nice loophole that saved me a > >great deal of overhead in time stamp updating (about 20%, as a matter > >of fact) and halved the number of system calls I had to make (combined > >lookup and stat). I have an 'ls' and a 'find' that both go about 220% > >the speed of the default implementations. 8-). > > I think this problem should be handled by caching the access time stamps > or even by storing them outside of inodes. The timestamps for all > directories can be cached in a tiny amount of memory on most systems. > (E.g., my 426MB usr partition has only 1932 directories so the access > times could be cached in only 8K or 16K.) This memory could be written > to disk very rarely (e.g., only when the fs is unmounted. POSIX doesn't > require timestamps to be preserved if the system panics ;-). This is somewhat of a non-sequitor. Typically "marked for update" is a euphamism for blowing the date information in the in core inode, then marking the inode as dirty meta-data by setting a vnode flag. When one writes out the other meta-data for reasons of referential integrity, it would result in the dates being written out too, and would actually require more effort to not write them than to write them (but there is the "added cost" of unmarking the vnode flag -- a trivial cost compared to the actual write). So the least astonishing behaviour is also a side effect of the least expensive behaviour -- subsequent references to an in core inode will get the updated date information. One could argue that "a POSIX file system" is any file system that conforms to the POSIX interface. If so, it's up to the implementor to decide where to draw the line (the kernel VFS, the kernel vncalls, the user space system call, or the user space library). Conformance is very much in the eye of the beholder, as it were. My personal preference would be to draw the line as high as possible for some things, like the API, and as low as possible for others, like event related meta-data. There must be internal logging of certain types of events, with file system dependent callback for update, to correctly support POSIX semantics with the largest possible sharing of code. For instance, it's necessary to note all "shall mark for update" events as formal events within the file system, and seperate the event processing out to common code for all file systems. One could consider the problem of a "Linux UMSDOS" type file system, where the actual meta-data maintained by the 'UMSDOS' file system is in the form of a 'poop file' in an underlying 'MSDOS' file system, with the POSIX update semantics being pushed down from above until they hit a point where they are discarded (the terminal file system can't cope with the request) or they are preemptorily implemented (the UMSDOS layer implements the 'poop files' as 'MSDOS' filesystem files). With the advent of the "Boot FreeBSD from a DOS file" recently discussed on the lists, this is a necessary step toward having a non-destructive FreeBSD install on top of an existing DOS file system. Further, use of the boot from a post-DOS-boot perspective means that the DOS drivers in the config.sys file have already been loaded -- then FreeBSD is a single VM86() interface away from being able to use DOS loaded ASPI and network drivers, for instance. DOS really would be used most appropriately: as a boot loader. Meanwhile, the arguments to the open() routine don't make it clear that it can't be open(3) instead of open(2); arguing back to the last exchange, one could envision that all system calls dealing with file descriptors be generalized as a single multiplex entry point, and that they all return stat information if the stat return pointer is non-NULL, plus an argument structure -- this also neatly resolves the lseek/off_t problem, at the cost of immediate backward compatability, while guaranteeing subsequent backward compatability. Generalizing further, the stat information returned is actually returned in a file system independent format, so there is either a requirement that the underlying file systems understand this format, or a requirement of a recall through a different vncall vector to return the information and have a single routine understand the file system independence (much like one should implement the file system independent dirent layout for use by the system call [vncalls] layer and for use by NFS). This avoids the potentially-too-small-caller-supplied-return-buffer problems of the current NFS export handling of this information. Well, I got carried away again... 8-). Time to move off to the file system list? Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501032035.AA06262>