Hi Olav,
I have a hunch that our problem was caused by improper unmounting of the
gluster volume, and have since found that the proper order should be: kill all
jobs using volume - unmount volume on clients - gluster volume stop - stop
gluster service (if necessary)
In my case, I wrote a
No, the files can be read on a newly mounted client! I went ahead and deleted
all of the link files associated with these duplicates, and then remounted the
volume. The problem is fixed!
Thanks again for the help, Joe and Vijay.
Tom
- Original Message - Subject: Re:
Moving the file with linkto attribute worked! Just one copy of the file is
retained in the listing and can be read without problems.
I will write a script to remove these rogue link files from the bricks - any
risks associated with this?
Thanks everyone for your help, of course if anyone could
Ok, I am really tearing my hair out here. I tried doing this manually for
several other files just to be sure. And in these cases it removed the
duplicate file from the directory listing, but the file can still not be read..
Reading directly from the brick works fine.
- Original
That didn't fix it unfortunately. In fact, I've done a full rebalance after
initially discovering the problem and after updating Gluster, but nothing was
changed..
I don't know too much about how Gluster works internally; is it possible to
compute the hash for each duplicate filename - figure
Thanks Joe, I've read your blog post as well as your post regarding the
.glusterfs directory.
I found some unneeded duplicate files which were not being read properly. I
then deleted the link file from the brick. This always removes the duplicate
file from the listing, but the file does not
Hi Vijay,
Yes the files are still readable from the .glusterfs path.
There is no explicit error. However, trying to read a text file in python
simply gives me null characters:
open('ott_mf_itab').readlines()
Hello everyone and happy holidays,
I upgraded both servers so that they are now both running Gluster 3.5.3, in
fact they are both running Fedora 20 with the same kernel version. We have only
one client and that is the first server itself, with plans to change this in
the future..
As per a
Thanks for your continued help Joe.
A demonstration of the problem, in this case I was able to open the file in vim
(a text file) without any issues, however sometimes duplicated text files open
in vim as one line consisting of @ characters, and binary data files can also
not be opened
Actually we are using XFS for the bricks. Still haven't made any progress on
this issue, unfortunately..
- Original Message - Subject: Re: [Gluster-users] Hundreds of
duplicate files
From: Anders Blomdell anders.blomd...@control.lth.se
Date: 12/21/14 7:42 pm
To:
Hi everyone,
We have a distributed Gluster volume on five bricks over two servers (first
server running gluster 3.4.2, second server running gluster 3.5.1, both running
Fedora 20)
Starting last week, doing a file listing on the mounted volume shows many files
with the same name appearing
Hi Joe,
Thanks for the reply. That worked; I probably forgot to do this as root last
time. Yet, the files still show up twice in a directory listing on the mounted
volume. And it seems to be random whether reading the file will succeed or not.
I've tried with several files and it sometimes
Hi everyone, we have noticed some extremely odd behaviour with our distributed
Gluster volume where duplicate files (same name, same or different content) are
being created and stored on multiple bricks. The only consistent clue is that
one of the duplicate files has the sticky bit set. I am
13 matches
Mail list logo
