[PVFS-developers] libpvfs: rename bug

[Porter Don]

 Ok, so I know why this is happening now, and uhh, don't use that patch I
sent earlier if you have folks that like to rename across devices, lest ye
lose thy data :)

The problem was that files created using the library always store a -1 in
their metadata file for the fs_ino.  Files created with the kernel would
store a 0.

Renaming through the kernel works because it checks for cross device renames
at a higher lever (I guess...).  Renaming through the library will fail
because it actually checks pvfs files to make sure that the fs_ino's are the
same.

1) file created with library renamed over file created by kernel
2) file created with kernel renamed over file created by library
3) file created by kernel renamed to non-existant name

So, where do these values come from...

library: In pvfs_detect, it calls MGR_ACCESS, which _should_ return ENOENT
but store the fs_ino in the ack structure.  It instead puts in a -1 for some
reason I don't understand.  This value is then passed in to the MGR_OPEN
call that creates the file, which is dutifully written to disk without
question.

kernel: in (k)pvfs_v1_xfer.c: create_pvfs_file, line 382/385:

	req.req.open.meta.fs_ino = 0; /* probably needs to be set... */

So, what is the right solution?  Shoud we just always store the right fs_ino
in, for instance, meta_write?  

In a way, this shows that it isn't all that important of a field.  I would
say just scrap it if we are filling in zeros, but I think that it is needed
for pvfs_rename to work safely :).  But maybe there is even a better way to
do that.  

It also seems that this could cause inode number collisions if you had
metadata directories on different disks and one manager if they were all
going into the same linked list because they all thought they are in fs
zero.

David Metheny and I figured out how to change mgr:do_access to return the
right fs_ino instead of -1 (attached), but I don't know enough about the
kernel code to know if there is even a good way to get that in the create
call other than to do an access call.  Is that stored somewhere?

Thoughts?

Thanks,
don

-----Original Message-----
From: Porter  Don
To: 'pvfs-developers at www.beowulf-underground.org '
Sent: 3/2/04 2:50 PM
Subject: [PVFS-developers] libpvfs: rename bug


In the pvfs_rename code, there is a check against cross-device links.
However, in certain cases, particularly directories, if the file does
not
exist, its fs_ino comes back from pvfs_detect as zero.  This doesn't
match
the fs_ino of the original file, so the call fails with an EXDEV.  

The real issue is probably why pvfs_detect is not consitantly filling in
the
right values for the fs_ino, but it isn't apparent to me.  Any thoughts?
I
can make renames always work correctly by checking if oldfs_ino and
newfs_ino are zero before comparing them.  See attached patch.

Any thoughts/suggestions on a better way to fix this are quite welcome.
Hope my explanation was clear.

Thanks,
don

 <<rename-1.6.3.patch>>  <<ATT194428.txt>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fs_ino-1.6.0.patch
Type: application/octet-stream
Size: 854 bytes
Desc: not available
Url : http://www.beowulf-underground.org/pipermail/pvfs-developers/attachments/20040302/3c0f9255/fs_ino-1.6.0.obj