Rajesh/Avra,
For one of the regression run [1] few uss testcases failed with core file. Can
you please take a look?
[1]
http://build.gluster.org/job/rackspace-regression-2GB-triggered/2821/consoleFull
~Atin
___
Gluster-devel mailing list
Gluster
I use glusterfs-experimental (glusterfs-freebsd 20140811) on FreeBSD 9 and
create distributed volume 2 node. Mount point to client node (Linux Centos 6.5)
when I move files or rename files client see files duplicate like this.
-rw--- 1 root root 762667 Nov 4 11:10 example. ---
- Original Message -
> From: "Atin Mukherjee"
> To: "Rajesh Joseph" , "Avra Sengupta"
>
> Cc: a-t...@redhat.com, gluster-devel@gluster.org
> Sent: Friday, November 21, 2014 2:07:28 PM
> Subject: USS test cases failure with core
>
> Rajesh/Avra,
>
> For one of the regression run [1] fe
Hi,
A new file create does not honour the force lookup avoidance - in my
case I am not interested in the attributes or forcing a lookup, just
need the inode details - is there a specific reason why !force_lookup
is not outside the block?
https://github.com/gluster/glusterfs/blob/master/api/src/gl
Hi,
I deleted a file by mistake in a brick. I never managed to find out its gfid so
now I have a rogue symlink in .glusterfs pointing to it (if I got how it works).
Any way I can discover which is this file and get rid of it?
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.r
first of all, links in .glusterfs are HARD links not symlinks. So the file is
not actually deleted, since the local filesystem keeps a count of references to
the inode and won't release the inode until the ref count reaches zero. I
tried this, it turns out you can find it with
# find /your
Hi Ben,
I have thousands of entries under /your/brick/directory/.glusterfs .. find
would return too many results.
How do I find the one I'm looking for? :-)
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
- Original Message -
> From: "Ben England"
> To: "Nux!"
Nux,
Those thousands of entries all would match "-links 2" but not "-links 1" The
only entry in .glusterfs that would match is the entry where you deleted the
file from the brick. That's how hardlinks work - when you create a regular
file, the link count is increased to 1 (since the directory
Fascinating, thanks, it indeed worked.
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
- Original Message -
> From: "Ben England"
> To: "Nux!"
> Cc: "Gluster Devel"
> Sent: Friday, 21 November, 2014 16:20:19
> Subject: Re: [Gluster-devel] How to resolve gfid (an
On Fri, 21 Nov 2014 11:20:19 -0500 (EST)
Ben England wrote:
> Nux,
>
> Those thousands of entries all would match "-links 2" but not "-links
> 1" The only entry in .glusterfs that would match is the entry where
> you deleted the file from the brick. That's how hardlinks work -
> when you create
Hi Rudra,
The inode and inode table data structures here represent the in-memory inode
on the client side.(gfapi)
When we are trying to create a new file, it becomes
*necessary* that we confirm with the backend if it can be created, hence
a force lookup.
Only case where we avoid a force lookup i
On Fri, 21 Nov 2014 15:42:13 +0700
Kajornsak Piyoungkorn wrote:
> I use glusterfs-experimental (glusterfs-freebsd 20140811) on FreeBSD
> 9
Ahhh, that's a pretty old snapshot of the code adding FreeBSD support,
so could be the cause of the problem.
Would you be ok to try using the FreeBSD Port v
Thanks for the response. In my case, I am trying to avoid doing the
network level lookup - since I use the same resolve only pass a null
for the attribute structure - essentially in my case, it is an atomic
multiple object read/write so I only want to resolve to the specific
bricks and then dispatc
example resolving 1 files with the fix -
Invocation:
ret = glfs_resolve (fs, subvol, objects[i], &loc, NULL, reval);
object [9998] = ./file_9998.txt, loc.inode (0xf11d7c), inode table
(0x7f62e0029ac0), name (meta-autoload/inode)
object [] = ./file_.txt, loc.inode (0xf11fcc),
On 11/21/2014 09:04 PM, Nux! wrote:
Hi,
I deleted a file by mistake in a brick. I never managed to find out its gfid so
now I have a rogue symlink in .glusterfs pointing to it (if I got how it works).
Any way I can discover which is this file and get rid of it?
symlinks exist in .glusterfs for
On 11/21/2014 09:50 PM, Ben England wrote:
Nux,
Those thousands of entries all would match "-links 2" but not "-links 1" The only entry in
.glusterfs that would match is the entry where you deleted the file from the brick. That's how hardlinks work - when
you create a regular file, the link
On 11/22/2014 12:10 PM, Pranith Kumar Karampuri wrote:
On 11/21/2014 09:50 PM, Ben England wrote:
Nux,
Those thousands of entries all would match "-links 2" but not "-links
1" The only entry in .glusterfs that would match is the entry where
you deleted the file from the brick. That's how
17 matches
Mail list logo
