That's a bug. After the attribute timeout (default 1s), it should show the new size. I broke it at some point--sorry about that. I'll fix it in the tree and it should be in the next release.
Some more info: There are two ways for a MacFUSE file system (kernel) to "catch up" to "remote" changes that didn't occur through the kernel: * If we are running with synchronous writes (the default and strongly recommended MacFUSE behavior), and if in a stat() call MacFUSE (kernel) realizes that the user-space daemon is returning a different file size than what we know about, we need to update our in-kernel size. Since size change means the file data has also changed, we have to purge the file's buffer cache as well (we don't know if the "remote" change actually changed existing file data or if it merely extended it; in the latter case, we wouldn't have to purge the cache, just adjust its size--but we don't know that, so we have to purge.) Note that this type of "catch up" will happen _only_ if a new stat happens on the file. That is, a stat call must happen *and* the attribute timeout must have occurred. If an open call occurs without a stat, subsequent reads/writes won't know about the new size. To handle even this case, the user-space file system can use explicit purging (see below) to tell the kernel to purge a file's cache as soon as it learns of a remote change. * Explicit purging is an experimental feature that will be in the new MacFUSE release. See <fuse/fuse_darwin.h> for function signatures. int fuse_purge_np(const char *mountpoint, const char *path, off_t *newsize); int fuse_knote_np(const char *mountpoint, const char *path, uint32_t note); fuse_purge_np() will purge a file's buffer and attribute caches in the kernel. If newsize is non-NULL, it will also update the file's in- kernel size. These updates will automatically generate appropriate kqueue events. If you want to generate custom kqueue events for a file at any time, you can use fuseknote_np(). See <sys/event.h> for EVFILT_VNODE events (things like NOTE_DELETE, NOTE_WRITE, ...). None of these are things a file system should do unless it ***REALLY*** knows what it's doing. If done wrong, these actions can have drastic effects on the file system, and can confuse applications no end. That's the flip side to making powerful knobs available to user programs. Amit On Jun 26, 6:29 pm, "Amar (ಅಮರ್ ತುಂಬಳ್ಳಿ)" <[EMAIL PROTECTED]> wrote: > Hi, > I have the filesystem mounted from two mac machine. (They use the > clustered, shared filesystem). The problem I have is, when I am writing from > one node, if I do the 'ls -l' (technically a readdir + stat/lookup) from > other node, the stat information is not updated. It shows the value of the > stat when it took it for the first time. I thought it may be a > attribute/entry/stat timeout problem, waited for some time, more than 5mins, > and again did a 'ls -l' on second machine, but still the stats are not > updated :( > > Here is the snippet of 'ls -l' on both machines, (note the difference in > size of test.10GB file. it never reached 10GB on second machine). > > I am using Leopard 10.5.3, and macfuse from svn (checked out yesterday). Any > pointers regarding this will be very helpful. > > mac1: > bash-3.2# df -h mnt/ > Filesystem Size Used Avail Capacity Mounted on > glusterfs 1.1Ti 13Gi 1.0Ti 2% /Users/zresearch/mnt > bash-3.2# > bash-3.2# ls -l mnt > total 26165272 > drwxr-xr-x 19 root wheel 4096 Jun 26 19:32 etc > drwxr-xr-x 2 root wheel 4096 Jun 25 22:25 glusterfs-1.4.0qa23 > -rw-r----- 1 root wheel 524288000 Jun 26 20:58 ioz1 > -rw-r----- 1 root wheel 524288000 Jun 26 20:59 ioz128 > -rw-r--r-- 1 root wheel 0 Jun 26 21:07 junk > -rw-r--r-- 1 root wheel 3 Jun 26 21:06 okpa > -rw-r--r-- 1 root wheel 10737418240 Jun 26 21:05 test.10GB > -rw-r--r-- 1 root wheel 536870912 Jun 26 20:56 testfile > -rw-r--r-- 1 root wheel 536870912 Jun 26 20:57 testfile128k > -rw-r--r-- 1 root wheel 536870912 Jun 26 20:57 testfile2m > bash-3.2# > > mac2: > bash-3.2# ls -l mnt > total 22550416 > drwxr-xr-x 19 root wheel 4096 Jun 26 19:32 etc > drwxr-xr-x 2 root wheel 4096 Jun 25 22:25 glusterfs-1.4.0qa23 > -rw-r----- 1 root wheel 524288000 Jun 26 20:58 ioz1 > -rw-r----- 1 root wheel 524288000 Jun 26 20:59 ioz128 > -rw-r--r-- 1 root wheel 0 Jun 26 21:07 junk > -rw-r--r-- 1 root wheel 0 Jun 26 21:06 okpa > -rw-r--r-- 1 root wheel 8886616064 Jun 26 21:05 test.10GB > -rw-r--r-- 1 root wheel 536870912 Jun 26 20:56 testfile > -rw-r--r-- 1 root wheel 536870912 Jun 26 20:57 testfile128k > -rw-r--r-- 1 root wheel 536870912 Jun 26 20:57 testfile2m > > Regards, > Amar > > -- > Amar Tumballi > Gluster/GlusterFS Hacker > [bulde on #gluster/irc.gnu.org]http://www.zresearch.com- Commoditizing Super > Storage! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" group. To post to this group, send email to macfuse-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse-devel?hl=en -~----------~----~----~----~------~----~------~--~---
