Re: Your comments, guidance, advice please :)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2012-08-13 at 15:55 +0100, Jim Vanns wrote:
> Hello NFS hackers. First off, fear not - the attached patch is not
> something I wish to submit to the mainline kernel! However, it is
> important for me that you pass judgement or comment on it. It is small.
> 
> Basically, I've written the patch solely to workaround a Bluearc bug
> where it duplicates fileids within an fsid and therefore we're not able
> to rely on the fsid+fileid to identify distinct files in an NFS
> filesystem. Some of our storage indexing and reporting software relies
> on this and works happily with other, more RFC-adherent
> implementations ;)
> 
> The functional change is one that modified the received fileid to a hash
> of the file handle as that, thankfully, is still unique. As with a
> fileid I need this hash to remain consistent for the lifetime of a file.
> It is used as a unique identifier in a database.
> 
> I'd really appreciate it if you could let me know of any problems you
> see with it - whether it'll break some client-side code, hash table use
> or worse still send back bad data to the server.
> 
> I've modified what I can see as the least amount of code possible - and
> my test VM is working happily as a client with this patch. It is
> intended that the patch modifies only client-side code once the Bluearc
> RPCs are pulled off the wire. I never want to send back these modified
> fileids to the server.

READDIR and READDIRPLUS will continue to return the fileid from the
server, so the getdents() and readdir() syscalls will be broken. Since
READDIRPLUS does return the filehandle, you might be able to fix that
up, but plain READDIR would appear to be unfixable.

Otherwise, your strategy should in principle be OK, but with the caveat
that a hash does not suffice to completely prevent collisions even if it
is well chosen.
IOW: All you are doing is tweaking the probability of a collision.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com

��.n��������+%������w��{.n�����{��w���jg��������ݢj����G�������j:+v���w�m������w�������h�����٥



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux