On Wed, Nov 14, 2012 at 02:46:42PM +0400, Pavel Emelyanov wrote: > Well, the MAX_HANDLE_SZ is taken from NFSv4 and is 128 bytes which is quite > big for inotify extension indeed. The good news is that this amount of bytes > seem to be required for the most descriptive fhandle That 128-byte constant is just the protocol-defined maximum. In practice my memory is that no existing filesystems require NFSv4 for exports, so they all fit in the NFSv3 64-byte limit. (But I seem to recall the NFSv2 32-byte limit being too small in some cases.) > -- with info about parent, etc. We don't need such, we can live with > shorter handle, people said that 40 bytes was enough for that. > > However, your idea about determining the handle size dynamically seems > promising. As far as I can see from the code we can call for > encode_fh with size equals zero and filesystem would report back the > amount of bytes it requires for a handle. > > We can try going this route, what do you think? I still don't understand why you need a dentry to get the filehandle. The current api may ask for one, but it shouldn't really be necessary (assuming you don't want parent directory information encoded in the filehandle, which I hope you don't). --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
