public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: John Groves <jgl@johngroves.net>
To: linux-xfs@oss.sgi.com
Cc: Vlad Apostolov <vapo@sgi.com>, John Groves <John@Groves.net>,
	Dean Roehrich <roehrich@sgi.com>
Subject: Re: XFS dmapi: dm_path_to_handle fails if the path is a directory
Date: Thu, 02 Nov 2006 19:00:22 -0600	[thread overview]
Message-ID: <454A94A6.6040907@johngroves.net> (raw)
In-Reply-To: <4547EDFD.8020407@sgi.com>

Thanks for your replies, Vlad, although I don't find anything so far 
that helps with my problem (my paths are not long, and my calls to 
dm_path_to_handle have been running in production environments for a 
couple of years).  As far as I can see, dm_path_to_handle does not work 
on a directory (?), although it works perfectly on a file.  I will try 
to dig deeper into this over the next few days, but here is a somewhat 
clearer explanation of the behavior I am seeing.

I have updated to the latest kernel from SGI's CVS server, but the 
problem is still there.  I am tracing through kernel code, and will be 
happy to pull together some test code that demonstrates the problem, or 
to post a patch if I figure it out, but this will take a few days.

The sequence in which I find this problem is:

    1. Receive a pre-rename event
    2. Use the first handle parameter to resolve the pre-rename parent 
directory path (not via dm_handle_to_path -- I had to roll my own 
mechanisms for turning handles into paths).
    3. Concatenate the first name parameter to the first parent 
directory path, to get the relative path from mount point to actual file 
being renamed.
    4. Call dm_path_to_handle on that path, hoping to get the handle of 
the file-being-renamed.

If the renamed-thing is a file, this works.  If it's a directory, 
dm_path_to_handle fails.

With my dmapi event handler installed and running, I can reproduce it by 
doing the following in the root directory of the filesystem:

mkdir -p x/y/z
mv x/y x/w

In the pre-rename event, prior to responding to the event, my handler 
correctly determines that x/y is being renamed to x/w, but 
dm_path_to_handle does not return the handle of x/y.  My post-rename 
event handler also correctly resolves the paths, but dm_path_to_handle 
does not return the handle of x/w.

If x/y is a file (rather than a directory) it all works properly.

Let me know if you can think of anything specific I should look at, or 
of a different way of getting the handle of the renamed thingy.

Thanks,
John Groves

Vlad Apostolov wrote:
> John Groves wrote:
> 
>> I'm running up against a difficult situation because dm_path_to_handle 
>> does not return a handle, if the path is to a directory.  Is this a 
>> known issue, or perhaps fixed in a recent version?  Or is there 
>> another way get the handle of a directory by path?  When any file type 
>> is renamed, I (for various reasons) *must* know not just the old & new 
>> parent handles, but also the handle of the renamed thingy.  If the 
>> thingy is a directory, I'm stuck at the moment.
>>
>> My test system has dmapi 2.2.1-5, which I don't think is current, but 
>> I can't seem to get access to the oss.sgi.com server to check.
>>
>> Any advice or info appreciated.  I'm willing to try and submit a 
>> patch, but I'd appreciate first knowing whether there was a specific 
>> reason or problem that led to the current behavior.
>>
>> Thanks,
>> John Groves
>>
> Hi John,
> 
> If your path is longer than 2000 characters dm_path_to_handle used to fail.
> This bug was fixed in August 2006. Please update your tree from here:
> 
> http://oss.sgi.com/projects/xfs/download.html
> 
> Regards,
> Vlad
> 
> 
> 
> 

  parent reply	other threads:[~2006-11-03  4:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-31 23:21 XFS dmapi: dm_path_to_handle fails if the path is a directory John Groves
2006-11-01  0:44 ` Vlad Apostolov
2006-11-01  0:57   ` Vlad Apostolov
2006-11-03  1:00   ` John Groves [this message]
2006-11-03  2:41     ` Vlad Apostolov
2006-11-03  2:53       ` John Groves
2006-11-03  2:59         ` Vlad Apostolov
2006-11-03 14:57           ` John Groves
2006-11-05 22:37             ` Vlad Apostolov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=454A94A6.6040907@johngroves.net \
    --to=jgl@johngroves.net \
    --cc=John@Groves.net \
    --cc=linux-xfs@oss.sgi.com \
    --cc=roehrich@sgi.com \
    --cc=vapo@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox