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
- Original Message -
From: Atin Mukherjee amukh...@redhat.com
To: Rajesh Joseph rjos...@redhat.com, Avra Sengupta
aseng...@redhat.com
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
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?
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
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 bengl...@redhat.com
To: Nux! n...@li.nux.ro
Cc: Gluster Devel gluster-devel@gluster.org
Sent: Friday, 21 November, 2014 16:20:19
On Fri, 21 Nov 2014 11:20:19 -0500 (EST)
Ben England bengl...@redhat.com 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
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
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
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
12 matches
Mail list logo
