Dear all, I saw some very strange behaviour of device files on Linux recently, thanks to a colleague. Can partly explain it, after all these years working with Unix, but my explanation has holes.
I'll explain the phenomenon not as I experienced it, but in brief, so that you don't have to recreate all the experimentation we did at our end to confine and reproduce the problem. :) It appears that if you have a diskless Linux machine, mounting all its file systems over NFS, then the device files that you see on the diskless machine do not hold their modification timestamp, even if a process holds the file open. And this may not be true of all device files, but is true of /dev/tty[0-9]. If you log in on /dev/tty1, for instance, and keep the shell running on that terminal, and do an ls -l /dev/tty1 from another terminal, then you'll see the modification timestamp of /dev/tty1 reflecting the last time you either typed on the keyboard or it displayed anything on the screen (i.e. the last I/O on tty1). At least, this is what should happen, and this is what indeed happens on all disk-ful Linux/Unix boxes. (This is how "w" gives you the idle time for each terminal session, for instance.) And this happens on a diskless Linux box too, with the /dev/pts/* devices. However, for the /dev/tty[0-9] devices on a diskless Linux box, the timestamp resets itself, after about a second or less. We tried to understand what the timestamp resets itself to. We found that it resets itself to the timestamp of the device inode for that device on the NFS server. This timestamp has not changed in years, because these devices are not accessed by anything on the NFS server; they're just left there for the diskless desktops to mount and use. For instance, /dev/tty1 on our desktop called "dc33" is actually mapped onto nfs:/export/linux/dc33/dev/tty1 which is a device file on the local hard disk of the machine called "nfs". This situation is really ridiculous, and we really highlighted this ridiculous scenario by doing the following: 1. Log in on tty1 and tty2 of a local diskless desktop. 2. While remaining logged in on tty1, run the following script on tty2: while :; do sleep 1 ls -l /dev/tty1 done 3. Occasionally do some small actions on tty1, like run "echo hello" or "ls", etc. And watch what happens on the continuous output on tty2. And this is what you get: crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Sep 19 12:43 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Sep 19 12:43 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Sep 19 12:44 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 crw--w---- 1 sanjog tty 4, 3 Aug 6 2000 /dev/tty1 As you can see, each time there's any I/O on tty1, the timestamp changes, but it resets to the old value within one second. And I can understand that NFS is stateless, hence the timestamps in the inode on the NFS server are not changed when they change on the NFS client. And I also understand that the NFS server will see the vfs_open() NFS call, but will not see any of the vfs_read() or vfs_write() calls, because, this being a device inode, those calls will be directed to the NFS's client's device driver layer, and not go across the wire to the NFS server. However: 1. The NFS client flushes data to the NFS server once every few seconds, hence the timestamp "must" get updated on the device file on the NFS server. Why doesn't it? This works fine for "normal" files and directories. The /dev/tty* files on the NFS server have not had their timestamps updated in three years (that was when we set up our office infrastructure). Why? Does this mean that an NFS client does not even bother to write back its in-core inode copies for device files? 2. The "ls" running on tty2 and the login session on tty1 are both running on the same diskless machine, hence both are doing the stat() system call on the same inode through the same kernel. The kernel will have its in-core copy of the inode which will have the correct timestamp, irrespective of what is flushed out to the NFS server. Therefore, that in-core copy should show the correct timestamp right through the login session at least. Remember, this inode is held open through the login session because the shell (at least) is a continuously running process on tty1, hence the in-core copy of the inode will not leave the kernel. 3. This problem does not appear with the /dev/pts/* devices. Their timestamps don't get reset every second. Hence, while I suspect this phenomenon is something to do with NFS (after all, it doesn't happen with non-NFS device files, e.g. on my laptop), my own explanation has plenty of holes in it. Any ideas? Shuvam PS: I don't have any reason to believe kernel version has anything to do with this, so unless you can point me to prior art that this is a kernel-version-specific bug, I won't get into "which RedHat version are you running?" And I'm _not_ running RedHat, so there. :) _______________________________________________ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd