Help save net neutrality! Learn more.
Close

#139 file sync wrong on cofs, command after mv/rename fails

v0.8.x (devel)
closed-fixed
Henry N.
5
2009-02-10
2008-10-18
Anonymous
No

I found some problem in cofs filesystem.
ex:
mv t1 t2
stat t2

many times I got "t2 not found".
it see like the second command exec before the first finished.

Discussion

  • Nobody/Anonymous

    Excuse me, I think this bug same as #2152550

     
  • Nobody/Anonymous

    I trace the code, it see like rename bug, the filename change, but inode not.

     
  • Henry N.

    Henry N. - 2008-10-22

    The inode cache is default enabled for 1 Second. You can disable it by adding "nocache" to mount options, for example:

    mount -o nocache -t cofs 0 /mnt/windows

    More cosf options, see cofs.txt in your coLinux installation or here:
    http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/doc/cofs

     
  • Nobody/Anonymous

    Close inode cache possible loss performance, it is a little bug in rename only.
    I fix this bug yesterday. and I will use the my new kernel some days,
    if that has other problem, I can fix it.

     
  • Henry N.

    Henry N. - 2008-10-27
    • summary: file sync wrong on cofs --> file sync wrong on cofs, command after mv/rename fails
     
  • Henry N.

    Henry N. - 2008-10-27

    With these script the "touch -d 1970-1-1 b" after the "mv" fails all times:
    rm -f a b
    touch a
    mv a b
    touch -d 1970-1-1 b
    ls --full-time b

    Same problem with overwrite on move:
    touch a b
    mv a b
    touch -d 1970-1-1 b
    ls --full-time b

    On cofs the touch after "mv" fails:
    touch: setting times of `b': No such file or directory
    -rw-r--r-- 1 root root 0 2008-10-27 23:29:50.000000000 +0000 b

    On cobd or with 'nocache' it works:
    -rw-r--r-- 1 root root 0 1970-01-01 00:00:00.000000000 +0000 b

     
  • Nobody/Anonymous

    Unfortunately, SVN revision r1127 do not fix this bug.
    When I remove my "d_move" patch, problem was recurrence.

     
  • Henry N.

    Henry N. - 2008-11-06

    Yes, SVN r1127 corrected only the swapped atime and mtime, and not the cache problem on rename.

    You have a patch? Nice. Please let's see.

     
  • Nobody/Anonymous

    Here is my patch, I do not known it is good way, but it work fine in my computer.

    static int fuse_rename(struct inode *olddir, struct dentry *oldent,
    struct inode *newdir, struct dentry *newent)
    {
    struct fuse_conn *fc = INO_FC(olddir);
    struct fuse_in in = FUSE_IN_INIT;
    struct fuse_out out = FUSE_OUT_INIT;
    struct fuse_rename_in inarg;

    memset(&inarg, 0, sizeof(inarg));
    inarg.newdir = newdir->i_ino;

    in.h.opcode = FUSE_RENAME;
    in.h.ino = olddir->i_ino;
    in.numargs = 3;
    in.args[0].size = sizeof(inarg);
    in.args[0].value = &inarg;
    in.args[1].size = oldent->d_name.len + 1;
    in.args[1].value = oldent->d_name.name;
    in.args[2].size = newent->d_name.len + 1;
    in.args[2].value = newent->d_name.name;
    request_send(fc, &in, &out);

    if (!out.h.error) {
    uncache_dir(olddir);
    + d_move(oldent, newent);
    if (olddir != newdir)
    uncache_dir(newdir);
    }

    return out.h.error;
    }

     
  • Henry N.

    Henry N. - 2008-11-12

    Yes, that solved this bug. NFS does it too. So it it very good. Thanks.
    What name I can honor in SVN? :-)

    Henry

     
  • Nobody/Anonymous

    chenm001 (chenm003 AT 163 DOT com)
    if this patch has any bug, please tell me, I will tract again.

     
  • Henry N.

    Henry N. - 2008-11-12
    • assigned_to: nobody --> henryn
    • status: open --> open-fixed
     
  • Henry N.

    Henry N. - 2008-11-12

    Your patch was committed to SVN as revision r1133.
    Thanks!

     
  • Henry N.

    Henry N. - 2008-11-30

    The d_move patch was replaced by inode_rename patch on host side,
    see SVN revision r1148 + r1149.

     
  • Henry N.

    Henry N. - 2009-02-10
    • labels: --> Daemons (Windows)
    • status: open-fixed --> closed-fixed
     
  • Henry N.

    Henry N. - 2009-02-10

    Think, can close this bug now.