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 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
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),
Hi Siva,
On 11/22/2014 08:44 AM, Rudra Siva wrote:
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 w
Thank you for the email. When expanded to multiple bricks, I did see
the inode-table not change - it pointed to the same inode table.
I don't want/need to resolve if the file exists just need the
potential brick information for each file and ability to dispatch as a
single fop with entries on that
If I understand the structure correctly, the lookup itself generally
may not pose a problem - specific flags triggering the over-the-wire
request for me at this time I wish to suppress (the fop on the backend
is fully capable of creating the file if it does not exist) - the
lookup drives through th
On 11/24/2014 07:43 AM, Rudra Siva wrote:
If I understand the structure correctly, the lookup itself generally
may not pose a problem - specific flags triggering the over-the-wire
request for me at this time I wish to suppress (the fop on the backend
is fully capable of creating the file if it do
The optimizations look good, I did find out that DHT is where the
information is for the specific volume so that is working well for me.
I'm testing for a 3 brick distributed volume at it gives the correct
sub volume to batch up the writes.
What gfapi is doing looks to be a little iffy to me (eg.
On 12/01/2014 07:25 AM, Rudra Siva wrote:
The optimizations look good, I did find out that DHT is where the
information is for the specific volume so that is working well for me.
I'm testing for a 3 brick distributed volume at it gives the correct
sub volume to batch up the writes.
What gfapi i
While I don't use glfs_creat - I was using it as a reference to some degree -
To me it looks wrong ... on two fronts -
1. a lookup is generated for most likely something that may just be a
non-existent file to begin with.
2. an open/create is attempted based on this lookup value - could have
more
On 12/01/2014 08:06 PM, Rudra Siva wrote:
While I don't use glfs_creat - I was using it as a reference to some degree -
To me it looks wrong ... on two fronts -
1. a lookup is generated for most likely something that may just be a
non-existent file to begin with.
This I agree, I am also not a
12 matches
Mail list logo
