Re: metadata race confition (was: ename(2) race condition)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 21, 2012 at 10:44:30PM -0700, Anand Avati wrote:
> Is there a way you can extend the trace code above to show the UIDs getting
> returned? Maybe it was the parent directory (subdir) that got a wrong UID
> returned?

Further investigation shows you are right. I traced the 
struct fuse_entry_out returned by glusterfs on LOOKUP;

"/subdir", uid = 500, gid = 500, mode = 040755, attr_valid = 1
"/subdir/bugc1.txt", uid = 500, gid = 500, mode = 0100644, attr_valid = 1
"/subdir/bugc1.txt", uid = 500, gid = 500, mode = 0100644, attr_valid = 1
"/subdir/bugc1.txt", uid = 500, gid = 500, mode = 0100644, attr_valid = 1

  bugc1.txt is looked up many times as I loop creating/deleting it
  subdir is not looked up often since it is cached for 1 second.
  New subdir lookups will return correct uid/gid/mode. After some time, 
  though, it will return incorrect information:
  
"/subdir/bugc1.txt", uid = 500, gid = 500, mode = 0100644, attr_valid = 1
"/subdir", uid = 0, gid = 0, mode = 040700, attr_valid = 1


-- 
Emmanuel Dreyfus
manu@xxxxxxxxxx



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux