Steve, Jeff,
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.
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.
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. This will in turn change the mod time on all relevant parent directories up to the root. 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.
Hope this helps.
Alan McLachlan Senior Systems Engineer Storage Management Solutions ASI Solutions www.asi.com.au Ph +61 2 6230 1566 Fax +61 2 6230 5343 Mobile +61 428 655644 e-mail amclachlan@asi.com.au
-----Original Message----- From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Thursday, 22 May 2003 7:30 AM To: Jeff Burton Cc: toasters@mathworks.com Subject: Re: Folder update time
Anyone know why DOT updates the modification time on a ntfs folder when a file in that folder is simply opened? This is not the way it works on our other NT systems. Is this a "feature", a bug, or just a difference between ntfs and wafl's interpretation of ntfs? I'm on a F880c running 6.3.1R1....and I'm a unix person so I may be missing the obvious, but I don't think so. Thanks,
Jeff Burton Storage Architect Abbott Laboratories EMAIL: Jeffrey.Burton@Abbott.com Dept. GB16/Bldg. AP14B-1 PHONE: 847-935-5778 100 Abbott Park Rd. FAX: 847-938-5824 Abbott Park, IL 60064-6042
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.
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.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
**** 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 ****
Steve, Jeff,
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.
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.
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. This will in turn change the mod time on all relevant parent directories up to the root. 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.
Hope this helps.
The file size, timestamps, and other metadata are stored in the file's inode. The inode is not stored in the directory. All the inodes for the entire volume are stored together in a table. (This table is actually a hidden file in the volume.)
A directory is a list of "dirents" (directory entries). A dirent consists of a file name and an inode number. The inode number is the index into inode table for the file's inode. In order to trip the mod time of a directory you need to either
1) add a dirent such as by creating a new file, or
2) remove a dirent by removing a file or
3) modify a dirent by renaming a file. (Renaming is often done by creating a new dirent and deleting the old one.)
Simply opening an existing file does nothing to its dirent, so it does not modify the directory. Of course any time that you search a directory, you trip its atime (access time).
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
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.
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".
On a traditional filesystem likeNTFS 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.
On Thu, May 22, 2003 at 11:59:22AM +1000, Alan McLachlan wrote:
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.
Nope. There is no file size attribute in directory entries; WAFL is a UNIXish file system, wherein file attributes are all stored in an inode, and the directory entry merely refers to the inode.
Remember, in WAFL all metadata lives in files. That includes directories.
That's not unique to WAFL - UNIX file systems have always done that, and FAT and NTFS do that as well.
On Thu, May 22, 2003 at 12:03:26PM -0700, Guy Harris wrote:
On Thu, May 22, 2003 at 11:59:22AM +1000, Alan McLachlan wrote:
Remember, in WAFL all metadata lives in files. That includes directories.
That's not unique to WAFL - UNIX file systems have always done that, and FAT and NTFS do that as well.
By "that" I meant" having directories be files - having all metadata (well, almost all metadata; there's one block in WAFL that's not in a file, which is the block that lets you find all the metadata) in a file isn't done by most UNIX file systems, although the Episode file system used with DFS might have done that, and I think a significant amount of the metadata in NTFS might be in files as well.
-
Alan McLachlan -
Chris Thompson -
Guy Harris -
Steve Losen