Wolfgang Alper:
> I see your point. Caching in aufs means to cache readdir request, not
> open/getdir/getattr request. Now it makes perfect sense. Maybe that is
> something that should be a bit more clear in the docs to help others as well.
Request is not cached. It is result that be cached, wh
Hello J. R.,
>Actually open(2) in your log took longer time than getdents(2).
>It indicates that the caching in aufs is not the cause the problem of your
>problem.
I see your point. Caching in aufs means to cache readdir request, not
open/getdir/getattr request. Now it makes perfect sense. Mayb
Wolfgang Alper:
> Great idea, pls find attached the requested traces.
:::
> - The branches themselves react as expected, regardless of the requested
> subdir structure.
> - aufs becomes slower using a more branches
> - requesting subdirs through aufs makes it slower, directly dependig on
Hello J. R.
>Here is another one.
>% strace -T ls /your/branches
>% strace -T ls /your/aufs
>From these outputs, we may able to find which systemcall took long time.
Great idea, pls find attached the requested traces.
Short description:
- Made tests with 8 branches and 81 branches.
- For testing
sf...@users.sourceforge.net:
> The easy way to find which operation is issued to the ftp server is
> watching on the ftp server. But you wrote that you don't know which
> operation is issued. So here is my suggestion.
>
> Test aufs readdir caching by using branches other than fuse. For
> example,
Wolfgang Alper:
> If the above seems to be correct, my question would be if there is an option
> to cache branch information or something similar to avoid re-reading branches
> (readdir), since the entire mountPoint can be considered RO (even the first
> branch if needed) and no udba is in effe
Hello J. R.,
>
>When you have any problems or strange behaviour in aufs, please let me
>know with:
>- /proc/mounts (instead of the output of mount(8))
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,
