On Thu, 17 Feb 2011, Yann Droneaud wrote:
quoted
On Wed, 16 Feb 2011, Yann Droneaud wrote:
quoted
Hi,
For some days, my usage of git is not as seamless as before.
I'm using git along sshfs/fuse (don't blame me for that), and
each time I try to rebase one of my branch, I have a conflict when
applying
the third commit. Doing the same operation on a local filesystem works
without any problem.
Yann, thanks for looking into this.
Your findings are not surprising: unlike NFS, sshfs doesn't provide
inode numbers and the fuse library also doesn't guarantee stable inode
numbers by default.
But why does it have such behavior when trying to rmdir() a non empty
directory ?
The VFS (part of the linux kernel that implements the generic
filesystem logic) clears the directory entry from the cache prior to
actually trying to remove the directory. This has the effect that any
children of the directory are also cleared from the cache, hence the
behavior you see in rmdir.
quoted
Fuse version 2.8.x has a "noforget" option that should provide stable
inode numbers, at the cost of unbounded memory use. Could you please
try if this option fixes these issues?
Yes, this option seems to fix the problem.
I will try it for a while to see if this is stable enough for a full day
of git working. (How can I check memory usage ?)
BTW, the [no]forget option did not appears in sshfs --help output.
Oh, that's an oversight on my part. Will fix.
Thanks,
Miklos
On Thu, 17 Feb 2011, Yann Droneaud wrote:
quoted
quoted
On Wed, 16 Feb 2011, Yann Droneaud wrote:
quoted
Hi,
For some days, my usage of git is not as seamless as before.
I'm using git along sshfs/fuse (don't blame me for that), and
each time I try to rebase one of my branch, I have a conflict when
applying
the third commit. Doing the same operation on a local filesystem
works
quoted
quoted
without any problem.
Yann, thanks for looking into this.
Your findings are not surprising: unlike NFS, sshfs doesn't provide
inode numbers and the fuse library also doesn't guarantee stable inode
numbers by default.
But why does it have such behavior when trying to rmdir() a non empty
directory ?
The VFS (part of the linux kernel that implements the generic
filesystem logic) clears the directory entry from the cache prior to
actually trying to remove the directory. This has the effect that any
children of the directory are also cleared from the cache, hence the
behavior you see in rmdir.
I tried to check that behavor: if the VFS is dropping dentry before doing
a rmdir(), them lookup files under this directory should be slower than
before rmdir().
On a ext4 filesystem, directory with 338 sub directories and 1992 files,
i've tried the following commands:
/* drop all */
# echo 3 > /proc/sys/vm/drop_caches
# time ls -alR directory > /dev/null
real 0m0.140s
user 0m0.000s
sys 0m0.080s
/* drop cache */
# echo 1 > /proc/sys/vm/drop_caches
# time ls -alR directory > /dev/null
real 0m0.119s
user 0m0.000s
sys 0m0.072s
/* drop dentry and inode */
# echo 2 > /proc/sys/vm/drop_caches
# time ls -alR directory > /dev/null
real 0m0.089s
user 0m0.016s
sys 0m0.040s
/* read from cache */
# time ls -alR directory > /dev/null
real 0m0.063s
user 0m0.004s
sys 0m0.036s
$ rmdir directory
rmdir: failed to remove `directory': Directory not empty
/* re read from cache */
$ time ls -alR directory > /dev/null
real 0m0.065s
user 0m0.012s
sys 0m0.036s
As you can see, after doing rmdir(), the time taken to walk trough the
directories is the same than before calling it, so the dentry seems not
flushed out of the cache after the rmdir().
I really prefer this behavior. The one you explained would be a real pain:
if one user call rmdir on / inside a loop, the full dentry cache will be
dropped each time: this would affect performance for the whole system.
But perhaps I doesn't understand how the VFS is working, which is the most
probable solution. Please correct me.
Regards.
--
Yann Droneaud