{"thread":{"id":"26525","subject":"inode problem when using git on a sshfs filesystem","startedAt":"2011-02-16T22:04:14Z","lastAt":"2011-02-18T07:41:16Z","messageCount":9,"participants":["Yann Droneaud","Michael J Gruber","Miklos Szeredi","Goswin von Brederlow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"161349","messageId":"1297893854.4097.43.camel@dworkin.quest-ce.net","threadId":"26525","inReplyTo":null,"subject":"inode problem when using git on a sshfs filesystem","fromName":"Yann Droneaud","fromEmail":"yann@droneaud.fr","sentAt":"2011-02-16T22:04:14Z","receivedAt":"2011-02-16T22:04:14Z","isPatch":false,"sender":{"key":"yann@droneaud.fr","avatar":null},"body":"Hi,\n\nFor some days, my usage of git is not as seamless as before.\n\nI'm using git along sshfs/fuse (don't blame me for that), and \neach time I try to rebase one of my branch, I have a conflict when applying\nthe third commit. Doing the same operation on a local filesystem works without any problem.\n\n===== Part one: git =====\n\nWhen I try to rebase one specific branch, git rebase failed when applying the third commit,\ntelling me about uncommited \n\nI've tried to do it from scratch, using git format-patch / git am\nbut git am also abort on the third patch with the error message:\n\nerror: /: does not match index\n\nSo I've tried to diagnose the problem using :\n\n - git diff / git status : doesn't return anything.\n\n - git ls-tree HEAD -l / : returns the correct mode and file size.\n\n - git log --raw --all --full-history -- / : \n returns valid information matching the one retrieved above.\n\n - git hash-object / :\n gives the correct sha1 for the file, as recorded in the patch extracted using git format-patch \n and reported by git ls-tree or git log (see before)\n\n - git diff-files : it shows a lot a file, all of them in same directory\n\n :100644 100644 0000000000000000000000000000000000000000 M /\n :100644 100644 0000000000000000000000000000000000000000 M /\n :100644 100644 0000000000000000000000000000000000000000 M /\n :100644 100644 0000000000000000000000000000000000000000 M /\n :100644 100644 0000000000000000000000000000000000000000 M /\n\nBTW, there's no conflict when applying the patch manually with patch: the patch itself is fine\nUsing git apply --index also work, but only if it's applied alone:\napply each patches in series and git apply fails in the same third patch.\n\nAfter diving into git source code and some debugging session, I've found\nthat the inode number recorded in the active_cache doesn't match the one\non the filesystem for / : that's why git apply --index refuse to apply the patch.\n\nThen I tried to monitor stat() information for the file in during\ngit operations.\n1) After applying the first patch, files in were affected different inode number\n2) Using strace, I checked that git apply didn't make anything specials to thoses files.\nThe only thing strange git did, was trying to unlink(), but this failed since the \ndirectory wasn't empty.\n\nNote: the first patch remove, change and add some files in directory, while \nthe third patch changes another file in directory\n\nAs a workaround: running git diff / git diff --cached / git status between each\ngit apply --index command seems to update the cache and allows me to apply all the patches\nwithout problem. But it's not an easy path to follow when rebasing branches.\n\nSurprisingly, when looking at strace output, it seems that git apply, once work done, is calling lstat() \nfor all the files under , and it sees the new inodes allocated to those files, but I don't know what \nit is doing with those information, if it's not stored in the index.\n\nTo conclude, it was a bit hard to diagnose from git point of view.\n\n====== Part two: sshfs / fuse ======\n\nAt this time sshfs seems to be guilty of bad behavior, breaking somes POSIX rules.\n\nSo I tried the following testcase on another computer to reproduce the\nproblem outside of git.\n\nHere the results:\n\n$ mkdir dir\n$ touch dir/a dir/b\n$ stat -t dir/*\ndir/a 0 0 81b4 500 500 15 3 1 0 0 1297882724 1297882724 1297882724 4096\ndir/b 0 0 81b4 500 500 15 4 1 0 0 1297882726 1297882726 1297882726 4096\n$ rmdir dir\nrmdir: failed to remove `dir1': Operation not permitted\n$ stat -t dir/*\ndir/a 0 0 81b4 500 500 15 6 1 0 0 1297882724 1297882724 1297882724 4096\ndir/b 0 0 81b4 500 500 15 7 1 0 0 1297882726 1297882726 1297882726 4096\n\nOne can see that inode 3 became inode 6 and inode 4 became inode 7 after the failed\nunlink operation on dir. Which seems to be a bit uncommon for me.\n\nNote: on a local filesystem, rmdir failed with message rmdir: failed to remove `dir1': Directory not empty\n\nI try to add some debug support to fuse / sshfs in order to locate more precisely the problem:\n(lines beginning by -/+ where added by me in libfuse, line beginning with --/++ in sshfs)\n\n$ sshfs localhost: -o sshfs_debug,debug,cache=no -d -f -s\n\nunique: 22, opcode: FORGET (2), nodeid: 4, insize: 48, pid: 0\n- forget 4\nFORGET 4/1\nDELETE: 4\n+ forget 4\nunique: 23, opcode: FORGET (2), nodeid: 3, insize: 48, pid: 0\n- forget 3\nFORGET 3/1\nDELETE: 3\n+ forget 3\nunique: 24, opcode: RMDIR (11), nodeid: 1, insize: 44, pid: 9044\n- rmdir 1 dir\nrmdir /dir\n-- rmdir(/dir)\n[00020] RMDIR\n [00020] STATUS 28bytes (0ms)\n++ rmdir(/dir) = -1\n unique: 24, error: -1 (Operation not permitted), outsize: 16\n+ rmdir 1 dir\nunique: 25, opcode: FORGET (2), nodeid: 2, insize: 48, pid: 0\n- forget 2\nFORGET 2/1\nDELETE: 2\n+ forget 2\n\nOne can see that the reference to files under the directory are asked by\nthe kernel to be forgotten, even if the directory is not yet removed.\n\nThis seems a bit illogical since a directory with files under it can't\nbe removed (but FORGET could apply to file deleted but still referenced\nby a process).\n\nNote: if the file is opened, the inode associated to the file name\ndidn't change. Hopefully.\n\nI've tried to reproduce the problem with other virtual filesystem like\nshm / tmpfs / devtmpfs / ramfs : no problem.\n\nI've also tried with NFS (local), and there's no problem too (the inode\nnumbers reported from NFS client side are the same than the server\nside).\n\nSo it seems this a FUSE only problem, and I haven't found exactly why.\n\nRegards.\n\n-- \nYann Droneaud\n\n\n\n------------------------------------------------------------------------------\nThe ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:\nPinpoint memory and threading errors before they happen.\nFind and fix more than 250 security defects in the development cycle.\nLocate bottlenecks in serial and parallel code that limit performance.\nhttp://p.sf.net/sfu/intel-dev2devfeb\n"},{"id":"161392","messageId":"4D5CDE58.5000905@drmicha.warpmail.net","threadId":"26525","inReplyTo":"1297893854.4097.43.camel@dworkin.quest-ce.net","subject":"Re: inode problem when using git on a sshfs filesystem","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-17T08:37:44Z","receivedAt":"2011-02-17T08:37:44Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Yann Droneaud venit, vidit, dixit 16.02.2011 23:04:\n> Hi,\n> \n> For some days, my usage of git is not as seamless as before.\n> \n> I'm using git along sshfs/fuse (don't blame me for that), and \n> each time I try to rebase one of my branch, I have a conflict when applying\n> the third commit. Doing the same operation on a local filesystem works without any problem.\n> \n> ===== Part one: git =====\n> \n> When I try to rebase one specific branch, git rebase failed when applying the third commit,\n> telling me about uncommited \n> \n> I've tried to do it from scratch, using git format-patch / git am\n> but git am also abort on the third patch with the error message:\n> \n> error: /: does not match index\n> \n> So I've tried to diagnose the problem using :\n> \n> - git diff / git status : doesn't return anything.\n> \n> - git ls-tree HEAD -l / : returns the correct mode and file size.\n> \n> - git log --raw --all --full-history -- / : \n> returns valid information matching the one retrieved above.\n> \n> - git hash-object / :\n> gives the correct sha1 for the file, as recorded in the patch extracted using git format-patch \n> and reported by git ls-tree or git log (see before)\n> \n> - git diff-files : it shows a lot a file, all of them in same directory\n> \n> :100644 100644 0000000000000000000000000000000000000000 M /\n> :100644 100644 0000000000000000000000000000000000000000 M /\n> :100644 100644 0000000000000000000000000000000000000000 M /\n> :100644 100644 0000000000000000000000000000000000000000 M /\n> :100644 100644 0000000000000000000000000000000000000000 M /\n> \n> BTW, there's no conflict when applying the patch manually with patch: the patch itself is fine\n> Using git apply --index also work, but only if it's applied alone:\n> apply each patches in series and git apply fails in the same third patch.\n> \n> After diving into git source code and some debugging session, I've found\n> that the inode number recorded in the active_cache doesn't match the one\n> on the filesystem for / : that's why git apply --index refuse to apply the patch.\n> \n> Then I tried to monitor stat() information for the file in during\n> git operations.\n> 1) After applying the first patch, files in were affected different inode number\n> 2) Using strace, I checked that git apply didn't make anything specials to thoses files.\n> The only thing strange git did, was trying to unlink(), but this failed since the \n> directory wasn't empty.\n> \n> Note: the first patch remove, change and add some files in directory, while \n> the third patch changes another file in directory\n> \n> As a workaround: running git diff / git diff --cached / git status between each\n> git apply --index command seems to update the cache and allows me to apply all the patches\n> without problem. But it's not an easy path to follow when rebasing branches.\n> \n> Surprisingly, when looking at strace output, it seems that git apply, once work done, is calling lstat() \n> for all the files under , and it sees the new inodes allocated to those files, but I don't know what \n> it is doing with those information, if it's not stored in the index.\n> \n> To conclude, it was a bit hard to diagnose from git point of view.\n> \n> ====== Part two: sshfs / fuse ======\n> \n> At this time sshfs seems to be guilty of bad behavior, breaking somes POSIX rules.\n> \n> So I tried the following testcase on another computer to reproduce the\n> problem outside of git.\n> \n> Here the results:\n> \n> $ mkdir dir\n> $ touch dir/a dir/b\n> $ stat -t dir/*\n> dir/a 0 0 81b4 500 500 15 3 1 0 0 1297882724 1297882724 1297882724 4096\n> dir/b 0 0 81b4 500 500 15 4 1 0 0 1297882726 1297882726 1297882726 4096\n> $ rmdir dir\n> rmdir: failed to remove `dir1': Operation not permitted\n> $ stat -t dir/*\n> dir/a 0 0 81b4 500 500 15 6 1 0 0 1297882724 1297882724 1297882724 4096\n> dir/b 0 0 81b4 500 500 15 7 1 0 0 1297882726 1297882726 1297882726 4096\n> \n> One can see that inode 3 became inode 6 and inode 4 became inode 7 after the failed\n> unlink operation on dir. Which seems to be a bit uncommon for me.\n> \n> Note: on a local filesystem, rmdir failed with message rmdir: failed to remove `dir1': Directory not empty\n> \n> I try to add some debug support to fuse / sshfs in order to locate more precisely the problem:\n> (lines beginning by -/+ where added by me in libfuse, line beginning with --/++ in sshfs)\n> \n> $ sshfs localhost: -o sshfs_debug,debug,cache=no -d -f -s\n> \n> unique: 22, opcode: FORGET (2), nodeid: 4, insize: 48, pid: 0\n> - forget 4\n> FORGET 4/1\n> DELETE: 4\n> + forget 4\n> unique: 23, opcode: FORGET (2), nodeid: 3, insize: 48, pid: 0\n> - forget 3\n> FORGET 3/1\n> DELETE: 3\n> + forget 3\n> unique: 24, opcode: RMDIR (11), nodeid: 1, insize: 44, pid: 9044\n> - rmdir 1 dir\n> rmdir /dir\n> -- rmdir(/dir)\n> [00020] RMDIR\n> [00020] STATUS 28bytes (0ms)\n> ++ rmdir(/dir) = -1\n> unique: 24, error: -1 (Operation not permitted), outsize: 16\n> + rmdir 1 dir\n> unique: 25, opcode: FORGET (2), nodeid: 2, insize: 48, pid: 0\n> - forget 2\n> FORGET 2/1\n> DELETE: 2\n> + forget 2\n> \n> One can see that the reference to files under the directory are asked by\n> the kernel to be forgotten, even if the directory is not yet removed.\n> \n> This seems a bit illogical since a directory with files under it can't\n> be removed (but FORGET could apply to file deleted but still referenced\n> by a process).\n> \n> Note: if the file is opened, the inode associated to the file name\n> didn't change. Hopefully.\n> \n> I've tried to reproduce the problem with other virtual filesystem like\n> shm / tmpfs / devtmpfs / ramfs : no problem.\n> \n> I've also tried with NFS (local), and there's no problem too (the inode\n> numbers reported from NFS client side are the same than the server\n> side).\n> \n> So it seems this a FUSE only problem, and I haven't found exactly why.\n> \n> Regards.\n> \n\nfuse-sshfs is a bit of a pita whenever you try to treat it like a \"real\"\nfile-system... OTOH, git makes assumptions on stability of device ids,\ne.g. On such a (non)-fs, I'd suggest to try in this order of preference:\n\n- Work from a local clone :) Pushing over ssh is fine.\n\n- Have your workdir on a local file system, gitdir on sshfs.\n\n- Try whether core.fsyncobjectfiles helps (shot in the dark).\n\n- Try whether core.ignoreStat works for you. (This impacts your workflow!)\n\nMichael\n"},{"id":"161401","messageId":"E1Pq1LW-0005rc-Qy@pomaz-ex.szeredi.hu","threadId":"26525","inReplyTo":"1297893854.4097.43.camel-vNW8ozRvgWupuGC+iAP0z+TW4wlIGRCZ@public.gmane.org","subject":"Re: [sshfs] inode problem when using git on a sshfs filesystem","fromName":"Miklos Szeredi","fromEmail":"miklos-sudqsbjrdhqhwmgevkv9ka@public.gmane.org","sentAt":"2011-02-17T10:44:26Z","receivedAt":"2011-02-17T10:44:26Z","isPatch":false,"sender":{"key":"miklos-sudqsbjrdhqhwmgevkv9ka@public.gmane.org","avatar":null},"body":"On Wed, 16 Feb 2011, Yann Droneaud wrote:\n> Hi,\n> \n> For some days, my usage of git is not as seamless as before.\n> \n> I'm using git along sshfs/fuse (don't blame me for that), and \n> each time I try to rebase one of my branch, I have a conflict when applying\n> the third commit. Doing the same operation on a local filesystem works without any problem.\n\nYann, thanks for looking into this.\n\nYour findings are not surprising: unlike NFS, sshfs doesn't provide\ninode numbers and the fuse library also doesn't guarantee stable inode\nnumbers by default.\n\nFuse version 2.8.x has a \"noforget\" option that should provide stable\ninode numbers, at the cost of unbounded memory use. Could you please\ntry if this option fixes these issues?\n\nThanks,\nMiklos\n\n> \n> ===== Part one: git =====\n> \n> When I try to rebase one specific branch, git rebase failed when applying the third commit,\n> telling me about uncommited \n> \n> I've tried to do it from scratch, using git format-patch / git am\n> but git am also abort on the third patch with the error message:\n> \n> error: /: does not match index\n> \n> So I've tried to diagnose the problem using :\n> \n> - git diff / git status : doesn't return anything.\n> \n> - git ls-tree HEAD -l / : returns the correct mode and file size.\n> \n> - git log --raw --all --full-history -- / : \n> returns valid information matching the one retrieved above.\n> \n> - git hash-object / :\n> gives the correct sha1 for the file, as recorded in the patch extracted using git format-patch \n> and reported by git ls-tree or git log (see before)\n> \n> - git diff-files : it shows a lot a file, all of them in same directory\n> \n> :100644 100644 0000000000000000000000000000000000000000 M /\n> :100644 100644 0000000000000000000000000000000000000000 M /\n> :100644 100644 0000000000000000000000000000000000000000 M /\n> :100644 100644 0000000000000000000000000000000000000000 M /\n> :100644 100644 0000000000000000000000000000000000000000 M /\n> \n> BTW, there's no conflict when applying the patch manually with patch: the patch itself is fine\n> Using git apply --index also work, but only if it's applied alone:\n> apply each patches in series and git apply fails in the same third patch.\n> \n> After diving into git source code and some debugging session, I've found\n> that the inode number recorded in the active_cache doesn't match the one\n> on the filesystem for / : that's why git apply --index refuse to apply the patch.\n> \n> Then I tried to monitor stat() information for the file in during\n> git operations.\n> 1) After applying the first patch, files in were affected different inode number\n> 2) Using strace, I checked that git apply didn't make anything specials to thoses files.\n> The only thing strange git did, was trying to unlink(), but this failed since the \n> directory wasn't empty.\n> \n> Note: the first patch remove, change and add some files in directory, while \n> the third patch changes another file in directory\n> \n> As a workaround: running git diff / git diff --cached / git status between each\n> git apply --index command seems to update the cache and allows me to apply all the patches\n> without problem. But it's not an easy path to follow when rebasing branches.\n> \n> Surprisingly, when looking at strace output, it seems that git apply, once work done, is calling lstat() \n> for all the files under , and it sees the new inodes allocated to those files, but I don't know what \n> it is doing with those information, if it's not stored in the index.\n> \n> To conclude, it was a bit hard to diagnose from git point of view.\n> \n> ====== Part two: sshfs / fuse ======\n> \n> At this time sshfs seems to be guilty of bad behavior, breaking somes POSIX rules.\n> \n> So I tried the following testcase on another computer to reproduce the\n> problem outside of git.\n> \n> Here the results:\n> \n> $ mkdir dir\n> $ touch dir/a dir/b\n> $ stat -t dir/*\n> dir/a 0 0 81b4 500 500 15 3 1 0 0 1297882724 1297882724 1297882724 4096\n> dir/b 0 0 81b4 500 500 15 4 1 0 0 1297882726 1297882726 1297882726 4096\n> $ rmdir dir\n> rmdir: failed to remove `dir1': Operation not permitted\n> $ stat -t dir/*\n> dir/a 0 0 81b4 500 500 15 6 1 0 0 1297882724 1297882724 1297882724 4096\n> dir/b 0 0 81b4 500 500 15 7 1 0 0 1297882726 1297882726 1297882726 4096\n> \n> One can see that inode 3 became inode 6 and inode 4 became inode 7 after the failed\n> unlink operation on dir. Which seems to be a bit uncommon for me.\n> \n> Note: on a local filesystem, rmdir failed with message rmdir: failed to remove `dir1': Directory not empty\n> \n> I try to add some debug support to fuse / sshfs in order to locate more precisely the problem:\n> (lines beginning by -/+ where added by me in libfuse, line beginning with --/++ in sshfs)\n> \n> $ sshfs localhost: -o sshfs_debug,debug,cache=no -d -f -s\n> \n> unique: 22, opcode: FORGET (2), nodeid: 4, insize: 48, pid: 0\n> - forget 4\n> FORGET 4/1\n> DELETE: 4\n> + forget 4\n> unique: 23, opcode: FORGET (2), nodeid: 3, insize: 48, pid: 0\n> - forget 3\n> FORGET 3/1\n> DELETE: 3\n> + forget 3\n> unique: 24, opcode: RMDIR (11), nodeid: 1, insize: 44, pid: 9044\n> - rmdir 1 dir\n> rmdir /dir\n> -- rmdir(/dir)\n> [00020] RMDIR\n> [00020] STATUS 28bytes (0ms)\n> ++ rmdir(/dir) = -1\n> unique: 24, error: -1 (Operation not permitted), outsize: 16\n> + rmdir 1 dir\n> unique: 25, opcode: FORGET (2), nodeid: 2, insize: 48, pid: 0\n> - forget 2\n> FORGET 2/1\n> DELETE: 2\n> + forget 2\n> \n> One can see that the reference to files under the directory are asked by\n> the kernel to be forgotten, even if the directory is not yet removed.\n> \n> This seems a bit illogical since a directory with files under it can't\n> be removed (but FORGET could apply to file deleted but still referenced\n> by a process).\n> \n> Note: if the file is opened, the inode associated to the file name\n> didn't change. Hopefully.\n> \n> I've tried to reproduce the problem with other virtual filesystem like\n> shm / tmpfs / devtmpfs / ramfs : no problem.\n> \n> I've also tried with NFS (local), and there's no problem too (the inode\n> numbers reported from NFS client side are the same than the server\n> side).\n> \n> So it seems this a FUSE only problem, and I haven't found exactly why.\n> \n> Regards.\n> \n> -- \n> Yann Droneaud\n\n------------------------------------------------------------------------------\nThe ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:\nPinpoint memory and threading errors before they happen.\nFind and fix more than 250 security defects in the development cycle.\nLocate bottlenecks in serial and parallel code that limit performance.\nhttp://p.sf.net/sfu/intel-dev2devfeb\n"},{"id":"161403","messageId":"7f02c4cb5ca13dae6de7caa1b6f90cfe.squirrel@webmail.ocsa-data.net","threadId":"26525","inReplyTo":"E1Pq1LW-0005rc-Qy@pomaz-ex.szeredi.hu","subject":"Re: [sshfs] inode problem when using git on a sshfs filesystem","fromName":"Yann Droneaud","fromEmail":"yann@droneaud.fr","sentAt":"2011-02-17T11:54:43Z","receivedAt":"2011-02-17T11:54:43Z","isPatch":false,"sender":{"key":"yann@droneaud.fr","avatar":null},"body":"> On Wed, 16 Feb 2011, Yann Droneaud wrote:\n>> Hi,\n>>\n>> For some days, my usage of git is not as seamless as before.\n>>\n>> I'm using git along sshfs/fuse (don't blame me for that), and\n>> each time I try to rebase one of my branch, I have a conflict when\n>> applying\n>> the third commit. Doing the same operation on a local filesystem works\n>> without any problem.\n>\n> Yann, thanks for looking into this.\n>\n> Your findings are not surprising: unlike NFS, sshfs doesn't provide\n> inode numbers and the fuse library also doesn't guarantee stable inode\n> numbers by default.\n>\n\nBut why does it have such behavior when trying to rmdir() a non empty\ndirectory ?\n\n> Fuse version 2.8.x has a \"noforget\" option that should provide stable\n> inode numbers, at the cost of unbounded memory use. Could you please\n> try if this option fixes these issues?\n>\n\nYes, this option seems to fix the problem.\n\nI will try it for a while to see if this is stable enough for a full day\nof git working. (How can I check memory usage ?)\n\nBTW, the [no]forget option did not appears in sshfs --help output.\n\nRegards.\n\n-- \nYann Droneaud\n"},{"id":"161406","messageId":"f0f23bdf3aedabac3a596ef6081009fb.squirrel@webmail.ocsa-data.net","threadId":"26525","inReplyTo":"1297893854.4097.43.camel@dworkin.quest-ce.net","subject":"Re: inode problem when using git on a sshfs filesystem","fromName":"Yann Droneaud","fromEmail":"yann@droneaud.fr","sentAt":"2011-02-17T12:05:58Z","receivedAt":"2011-02-17T12:05:58Z","isPatch":false,"sender":{"key":"yann@droneaud.fr","avatar":null},"body":"> Hi,\n>\n> For some days, my usage of git is not as seamless as before.\n>\n> I'm using git along sshfs/fuse (don't blame me for that), and\n> each time I try to rebase one of my branch, I have a conflict when\n> applying\n> the third commit. Doing the same operation on a local filesystem works\n> without any problem.\n>\n> ===== Part one: git =====\n>\n> When I try to rebase one specific branch, git rebase failed when applying\n> the third commit,\n> telling me about uncommited\n>\n\nFor the record, here's the exact message for a rebase:\n\n$ git rebase origin\nFirst, rewinding head to replay your work on top of it...\nApplying: patch1\nApplying: patch2\nApplying: patch3\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nerror: Your local changes to '/' would be overwritten by\nmerge. Aborting.\nPlease, commit your changes or stash them before you can merge.\nFailed to merge in the changes.\nPatch failed at 0003 patch3\n\n\n> As a workaround: running git diff / git diff --cached / git status between\n> each\n> git apply --index command seems to update the cache and allows me to apply\n> all the patches\n> without problem. But it's not an easy path to follow when rebasing\n> branches.\n>\n\nThe exact command to update the index is \"git diff\".\n\nRegards.\n\n-- \nYann Droneaud\n"},{"id":"161419","messageId":"E1Pq3aa-0006Nn-Cv@pomaz-ex.szeredi.hu","threadId":"26525","inReplyTo":"7f02c4cb5ca13dae6de7caa1b6f90cfe.squirrel@webmail.ocsa-data.net","subject":"Re: [sshfs] inode problem when using git on a sshfs filesystem","fromName":"Miklos Szeredi","fromEmail":"miklos@szeredi.hu","sentAt":"2011-02-17T13:08:08Z","receivedAt":"2011-02-17T13:08:08Z","isPatch":false,"sender":{"key":"miklos@szeredi.hu","avatar":null},"body":"On Thu, 17 Feb 2011, Yann Droneaud wrote:\n> > On Wed, 16 Feb 2011, Yann Droneaud wrote:\n> >> Hi,\n> >>\n> >> For some days, my usage of git is not as seamless as before.\n> >>\n> >> I'm using git along sshfs/fuse (don't blame me for that), and\n> >> each time I try to rebase one of my branch, I have a conflict when\n> >> applying\n> >> the third commit. Doing the same operation on a local filesystem works\n> >> without any problem.\n> >\n> > Yann, thanks for looking into this.\n> >\n> > Your findings are not surprising: unlike NFS, sshfs doesn't provide\n> > inode numbers and the fuse library also doesn't guarantee stable inode\n> > numbers by default.\n> >\n> \n> But why does it have such behavior when trying to rmdir() a non empty\n> directory ?\n\nThe VFS (part of the linux kernel that implements the generic\nfilesystem logic) clears the directory entry from the cache prior to\nactually trying to remove the directory. This has the effect that any\nchildren of the directory are also cleared from the cache, hence the\nbehavior you see in rmdir.\n\n> \n> > Fuse version 2.8.x has a \"noforget\" option that should provide stable\n> > inode numbers, at the cost of unbounded memory use. Could you please\n> > try if this option fixes these issues?\n> >\n> \n> Yes, this option seems to fix the problem.\n> \n> I will try it for a while to see if this is stable enough for a full day\n> of git working. (How can I check memory usage ?)\n> \n> BTW, the [no]forget option did not appears in sshfs --help output.\n\nOh, that's an oversight on my part. Will fix.\n\nThanks,\nMiklos\n"},{"id":"161433","messageId":"ac00e83c1b57e2eeda1c6631ec611e75.squirrel@webmail.ocsa-data.net","threadId":"26525","inReplyTo":"E1Pq3aa-0006Nn-Cv@pomaz-ex.szeredi.hu","subject":"Re: [sshfs] inode problem when using git on a sshfs filesystem","fromName":"Yann Droneaud","fromEmail":"yann@droneaud.fr","sentAt":"2011-02-17T18:11:14Z","receivedAt":"2011-02-17T18:11:14Z","isPatch":false,"sender":{"key":"yann@droneaud.fr","avatar":null},"body":"> On Thu, 17 Feb 2011, Yann Droneaud wrote:\n>> > On Wed, 16 Feb 2011, Yann Droneaud wrote:\n>> >> Hi,\n>> >>\n>> >> For some days, my usage of git is not as seamless as before.\n>> >>\n>> >> I'm using git along sshfs/fuse (don't blame me for that), and\n>> >> each time I try to rebase one of my branch, I have a conflict when\n>> >> applying\n>> >> the third commit. Doing the same operation on a local filesystem\n>> works\n>> >> without any problem.\n>> >\n>> > Yann, thanks for looking into this.\n>> >\n>> > Your findings are not surprising: unlike NFS, sshfs doesn't provide\n>> > inode numbers and the fuse library also doesn't guarantee stable inode\n>> > numbers by default.\n>> >\n>>\n>> But why does it have such behavior when trying to rmdir() a non empty\n>> directory ?\n>\n> The VFS (part of the linux kernel that implements the generic\n> filesystem logic) clears the directory entry from the cache prior to\n> actually trying to remove the directory. This has the effect that any\n> children of the directory are also cleared from the cache, hence the\n> behavior you see in rmdir.\n>\n\nI tried to check that behavor: if the VFS is dropping dentry before doing\na rmdir(), them lookup files under this directory should be slower than\nbefore rmdir().\n\nOn a ext4 filesystem, directory with 338 sub directories and 1992 files, \ni've tried the following commands:\n\n/* drop all */\n# echo 3 > /proc/sys/vm/drop_caches\n# time ls -alR directory > /dev/null\nreal\t0m0.140s\nuser\t0m0.000s\nsys\t0m0.080s\n\n/* drop cache */\n# echo 1 > /proc/sys/vm/drop_caches\n# time ls -alR directory > /dev/null\nreal\t0m0.119s\nuser\t0m0.000s\nsys\t0m0.072s\n\n/* drop dentry and inode */\n# echo 2 > /proc/sys/vm/drop_caches\n# time ls -alR directory > /dev/null\nreal\t0m0.089s\nuser\t0m0.016s\nsys\t0m0.040s\n\n/* read from cache */\n# time ls -alR directory > /dev/null\nreal\t0m0.063s\nuser\t0m0.004s\nsys\t0m0.036s\n\n$ rmdir directory\nrmdir: failed to remove `directory': Directory not empty\n\n/* re read from cache */\n$ time ls -alR directory > /dev/null\nreal\t0m0.065s\nuser\t0m0.012s\nsys\t0m0.036s\n\nAs you can see, after doing rmdir(), the time taken to walk trough the\ndirectories is the same than before calling it, so the dentry seems not\nflushed out of the cache after the rmdir().\n\nI really prefer this behavior. The one you explained would be a real pain:\nif one user call rmdir on / inside a loop, the full dentry cache will be\ndropped each time: this would affect performance for the whole system.\n\nBut perhaps I doesn't understand how the VFS is working, which is the most\nprobable solution. Please correct me.\n\nRegards.\n\n-- \nYann Droneaud\n"},{"id":"161444","messageId":"E1PqA19-00080P-Dy@pomaz-ex.szeredi.hu","threadId":"26525","inReplyTo":"ac00e83c1b57e2eeda1c6631ec611e75.squirrel@webmail.ocsa-data.net","subject":"Re: [sshfs] inode problem when using git on a sshfs filesystem","fromName":"Miklos Szeredi","fromEmail":"miklos@szeredi.hu","sentAt":"2011-02-17T19:59:59Z","receivedAt":"2011-02-17T19:59:59Z","isPatch":false,"sender":{"key":"miklos@szeredi.hu","avatar":null},"body":"On Thu, 17 Feb 2011, Yann Droneaud wrote:\n> > The VFS (part of the linux kernel that implements the generic\n> > filesystem logic) clears the directory entry from the cache prior to\n> > actually trying to remove the directory. This has the effect that any\n> > children of the directory are also cleared from the cache, hence the\n> > behavior you see in rmdir.\n> >\n> \n> I tried to check that behavor: if the VFS is dropping dentry before doing\n> a rmdir(), them lookup files under this directory should be slower than\n> before rmdir().\n> \n> On a ext4 filesystem, directory with 338 sub directories and 1992 files, \n> i've tried the following commands:\n> \n> /* drop all */\n> # echo 3 > /proc/sys/vm/drop_caches\n> # time ls -alR directory > /dev/null\n> real\t0m0.140s\n> user\t0m0.000s\n> sys\t0m0.080s\n> \n> /* drop cache */\n> # echo 1 > /proc/sys/vm/drop_caches\n> # time ls -alR directory > /dev/null\n> real\t0m0.119s\n> user\t0m0.000s\n> sys\t0m0.072s\n> \n> /* drop dentry and inode */\n> # echo 2 > /proc/sys/vm/drop_caches\n> # time ls -alR directory > /dev/null\n> real\t0m0.089s\n> user\t0m0.016s\n> sys\t0m0.040s\n> \n> /* read from cache */\n> # time ls -alR directory > /dev/null\n> real\t0m0.063s\n> user\t0m0.004s\n> sys\t0m0.036s\n> \n> $ rmdir directory\n> rmdir: failed to remove `directory': Directory not empty\n> \n> /* re read from cache */\n> $ time ls -alR directory > /dev/null\n> real\t0m0.065s\n> user\t0m0.012s\n> sys\t0m0.036s\n> \n> As you can see, after doing rmdir(), the time taken to walk trough the\n> directories is the same than before calling it, so the dentry seems not\n> flushed out of the cache after the rmdir().\n\ntucsk:~ # time find /usr -ls > /dev/null\n\nreal 0m1.922s\nuser 0m1.104s\nsys 0m0.800s\ntucsk:~ # rmdir /usr\nrmdir: failed to remove `/usr': Directory not empty\ntucsk:~ # time find /usr -ls > /dev/null\n\nreal 0m2.637s\nuser 0m1.172s\nsys 0m1.448s\ntucsk:~ # time find /usr -ls > /dev/null\n\nreal 0m1.943s\nuser 0m1.068s\nsys 0m0.848s\ntucsk:~ # \n\nAs you can see it does get significantly slower after the rmdir.\n\n> I really prefer this behavior. The one you explained would be a real pain:\n> if one user call rmdir on / inside a loop, the full dentry cache will be\n> dropped each time: this would affect performance for the whole system.\n\nYes. But in practice this doesn't really matter, removing non-empty\ndirectories happens rarely.\n\nThanks,\nMiklos\n"},{"id":"161516","messageId":"87ei75ssbn.fsf@frosties.localnet","threadId":"26525","inReplyTo":"7f02c4cb5ca13dae6de7caa1b6f90cfe.squirrel@webmail.ocsa-data.net","subject":"Re: [fuse-devel] [sshfs] inode problem when using git on a sshfs filesystem","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2011-02-18T07:41:16Z","receivedAt":"2011-02-18T07:41:16Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"\"Yann Droneaud\" writes:\n\n>> On Wed, 16 Feb 2011, Yann Droneaud wrote:\n>> Fuse version 2.8.x has a \"noforget\" option that should provide stable\n>> inode numbers, at the cost of unbounded memory use. Could you please\n>> try if this option fixes these issues?\n>>\n>\n> Yes, this option seems to fix the problem.\n>\n> I will try it for a while to see if this is stable enough for a full day\n> of git working. (How can I check memory usage ?)\n\nThe memory usage comes from the inodes. Fuse will never forget an inode\n(unless you delete the dile/dir) that was once visited (thereby giving\nallways the same inode number). As long as you don't have a billion\nfiles that generally doesn't matter.\n\nMfG\n Goswin\n"}]}