Shyam, > These files are linkto files that are created by DHT, which basically mean > the files were either renamed, or the brick layout changed (I suspect the > former to be the cause). > > These files should have been deleted when the files that they point to were > deleted, looks like this did not happen.
Could these linkto files be causing my performance issues? I will forward you a couple of emails that I sent Ben and justin related to severe performance issues I am having with gluster. > >> On 02/08/2015 12:19 PM, David F. Robinson wrote: >> I am seeing these messsages after I delete large amounts of data using >> gluster 3.6.2. >> cannot delete non-empty directory: >> old_shelf4/Aegis/!!!Programs/RavenCFD/Storage/Jimmy_Old/src_vj1.5_final >> *_From the FUSE mount (as root), the directory shows up as empty:_* >> # pwd >> /backup/homegfs/backup.0/old_shelf4/Aegis/!!!Programs/RavenCFD/Storage/Jimmy_Old/src_vj1.5_final >> >> # ls -al >> total 5 >> d--------- 2 root root 4106 Feb 6 13:55 . >> drwxrws--- 3 601 dmiller 72 Feb 6 13:55 .. >> However, when you look at the bricks, the files are still there (none on >> brick01bkp, all files are on brick02bkp). All of the files are 0-length >> and have ------T permissions. > > These files are linkto files that are created by DHT, which basically mean > the files were either renamed, or the brick layout changed (I suspect the > former to be the cause). > > These files should have been deleted when the files that they point to were > deleted, looks like this did not happen. > > Can I get the following information for some of the files here, > - getfattr -d -m . -e text <path to file on brick> > - The output of trusted.glusterfs.dht.linkto xattr should state where the > real file belongs, in this case as there are only 2 bricks, it should be > brick01bkp subvol > - As the second brick is empty, we should be able to safely delete these > files from the brick and proceed to do an rmdir on the mount point of the > volume as the directory is now empty. > - Please check, the one sub-directory that is showing up in this case as > well, "save1" > >> Any suggestions on how to fix this and how to prevent it from happening? > > I believe there are renames happening here, possibly by the archive creator, > one way to prevent the rename from creating a linkto file is to use the DHT > set parameter to set a pattern so that file name hash considers only the > static part of the name. > > The set parameter is, cluster.extra-hash-regex. > > A link on a similar problem and how to use this set parameter (there a few in > the gluster forums) would be, > http://www.gluster.org/pipermail/gluster-devel/2014-November/042863.html > > Additionally, there is a bug here, the unlink of the file should have cleaned > up the linkto as well, so that all of the above is not required, we have > noticed this with NFS and FUSE mounts (ref bugs, 1117923, 1139992), and > investigation is in progress on the same. We will step up the priority on > this so that we have a clean fix that can be used to prevent this in the > future. > > Shyam
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
