Hi Chris,
I had assumed that atime was stored in the directory entry itself (which would have a pointer to an inode that was a simple list of data blocks), which would have explained the behaviour reported by Jeff Burton in his post. TR2002 ("Filesystem Design for an NFS file server appliance") doesn't specify anything about directory entry contents. The testing you show below seems to nails it, but I will go and have a play when I get a moment just fo see it for myself.
Now, even if the directory entry doesn't contain the attributes but is simply a name with a pointer to an inode that contains the file attributes, a change in the file attributes will still require the pointer in the directory entry to be changed to point to the new inode. (WAFL NEVER makes changes to existing inodes, it always writes new ones). Therefore the block containing that directory entry will still need to be rewritten (you seem to imply that it won't).
If you are at least partly right it would mean that OnTAP is deliberately ignoring the change to directory entries in order to appear more consistent with traditional filesystem behaviour. This still doesn't help us solve Jeff's problem...
-----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Friday, 23 May 2003 12:48 AM To: amclachlan@asi.com.au Cc: toasters@mathworks.com Subject: Re: Folder update time
Alan McLachlan writes:
A write to a file will change the file size attribute in the directory entry, which will of course change the mod time on the directory itself.
No, it doesn't:
$ ls -ld temp temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 21 May 22 09:00 temp/foobar $ echo foobar >>temp/foobar $ ls -ld temp temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 28 May 22 15:19 temp/foobar
In fact, if you don't have "atime update" turned OFF, even opening a file will change the directory mod time since the access time attribute for the file needs to be updated in the directory entry.
No, it doesn't:
$ ls -ld temp; ls -ldu temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 28 May 22 15:17 temp/foobar $ cat temp/foobar Oh what a goose I am foobar $ ls -ld temp; ls -ldu temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 28 May 22 15:22 temp/foobar
(That was done on a different client from the previous test. Client-side caching can confuse attempts to look at atimes otherwise.)
Remember, in WAFL all metadata lives in files. That includes directories.
So
ANY change to a directory entry will cause the modification time on the directory to be updated.
But the directory entry doesn't change. It's the inode that changes. You seem to have confused the two.
Alan: No I haven't. I had simply assumed that mtime and atime were both
stored in the directory entry itself. However, your are wrong here: the directory entry still has to change to reflect the new inode location. The inode doesn't "change", a new version of it is written elsewhere. Don't confuse WAFL with UFS...
This will in turn change the mod time on allrelevant parent directories up to the root.
Restate that as "the relevant block in the inode metafile has been changed, so all the index blocks up to the root have to be rewritten as well".
Alan: See above. All directories must change as well since the inodes
their entries point to are relocated as part of the CP. Even if the directory entry has a pointer to the file ino
On a traditional filesystem
like
NTFS or UFS this would be a performance disaster as it would generate lots of additional seeks, so they don't do it. However in WAFL an change to a file will cause all relevant metadata inodes up to the root inode to be rewritten [in new locations without seeks] anyway, without a performance cost.
All the changed blocks will (usually) be written close together as part of the next checkpoint. But none of these blocks are directory blocks, or blocks containing the inode for the directory (unless they happen to be the same block as that containing the inode for the file).
Hope this helps.
Honestly, I don't think it did.
Steve Losen wrote: ] ] My guess is that the application is doing more than a simple file open. ] Perhaps it is an editor that is creating a .bak file or something like ] that. As far as I know, to change the mod time of a directory (folder) ] you need to create, delete, or rename a file in the directory. Simply ] reading or writing an existing file does not change the directory mod ] time. An application could also explicitly set the mod time of the ] directory.
Another possibility is that the application is deleting and then re-creating the file, which would certainly change the mtime and ctime of the directory. Jeff Burton didn't make it very clear whether the "simple open" was for reading or writing.
] I can think of one other possibility, but I have doubts since this is ] a NTFS volume. If you create a directory with NFS, then it is not in ] unicode format (unless you specify an option to change this). ] The first time you access the directory via CIFS, it is converted to ] unicode, and this might also trip the directory mod time, but I don't ] know. Of course, this only happens once at the first CIFS access.
That obviously changes the directory contents, but does it change its mtime (or even the ctime)? I can't do that experiment here as we aren't licensed for CIFS access.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
**** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001.
This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited.
E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****
Hi Chris,
I had assumed that atime was stored in the directory entry itself (which would have a pointer to an inode that was a simple list of data blocks), which would have explained the behaviour reported by Jeff Burton in his post. TR2002 ("Filesystem Design for an NFS file server appliance") doesn't specify anything about directory entry contents. The testing you show below seems to nails it, but I will go and have a play when I get a moment just fo see it for myself.
Now, even if the directory entry doesn't contain the attributes but is simply a name with a pointer to an inode that contains the file attributes, a change in the file attributes will still require the pointer in the directory entry to be changed to point to the new inode. (WAFL NEVER makes changes to existing inodes, it always writes new ones). Therefore the block containing that directory entry will still need to be rewritten (you seem to imply that it won't).
The directory entry does not need to be changed because it contains an inode number (index into the inode table). This is not a pointer to a specific disk block. It is an offset from the beginning of the inode file to a particular inode.
The inode table is simply a sequential list of inodes, i.e., an array. When an inode is modified, you are correct that wafl must replace the disk block that contains the old inode with a new disk block with the updated inode. But this is a bookkeeping detail. Logically, the inode is updated in place. Therefore its offset (inode number) does not change, so the directory entry does not change either.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
-
Alan McLachlan -
Steve Losen