Messages in this thread | | | Date | Sat, 21 Feb 2004 08:58:53 +0100 | From | Ingo Molnar <> | Subject | Re: explicit dcache <-> user-space cache coherency, sys_mark_dir_clean(), O_CLEAN |
| |
* Ingo Molnar <mingo@elte.hu> wrote:
> perhaps using a simple 64-bit generation counter would be better. > Samba would get a new syscall to get the sum of each generation > counter down to the root dentry - a total validation of the pathname. > If the counter matches with that in the userspace cache entry then no > need to re-create the cache. Such generation counters would be usable > for multiple file servers as well. Hm?
generation counters are problematic if they are not persistent. But there's a pretty natural persistent 'generation counter' which could be used for Samba's purpose: the mtime of the directory. The problem right now is that it doesnt have enough resolution to be a true unique generation counter. But having high-resolution mtime is a goal anyway.
XFS is one filesystem that has high-resolution mtime:
typedef struct xfs_timestamp { __int32_t t_sec; /* timestamp seconds */ __int32_t t_nsec; /* timestamp nanoseconds */ } xfs_timestamp_t;
monotonity is important: two successive directory operations to not be possible within the same nanosecond. This is not possible with current hardware - but how about future hardware? Can we make an assumption like this?
hardware that has no high-resolution clock can be supported too: by forcing mtime to be monotonic: if current time <= last_mtime, then last_mtime++.
so there's only one new syscall necessary for Samba to validate its name cache:
sys_get_path_timestamp(char *path, struct timeval *tv);
this returns the _largest_ (youngest) timestamp out of the dentry chain down to the root dentry. This is in essence the 'age' of the whole path, with all components taken into account. If any directory along the path is renamed, the age changes automatically.
filesystems that dont have 64-bit, monotonic timestamps will return -ENOSYS. This should include even XFS at the moment, because the timestamp is not guaranteed to be monotonic.
if any path component down the tree doesnt support monotonic timestamps, then -ENOSYS is returned. (In mixed-type filesystem installations chroot() can be used to limit Samba's root to a monotonic timestamp capable filesystem.)
there's at least one problem with this approach:
- the 'age' of a path changes more often than what Samba's caching needs are: e.g. it changes if any directory within the path is written to.
but this is not a big problem i believe - the fastpath is preserved and a mechanism is presented to validate the cache with a single syscall.
any other problems with this concept?
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |