"Steven J. Magnani" <st...@digidescorp.com> writes: >> How do you prevent to modify or free the those inode/blocks from other >> path? Yeah, it is racy. And if races is not solved, that's simply wrong >> and not solution. >> >> Although I'm not thinking deeply about NFS support on FAT. Just a idea, >> the one of possible solutions would be register it to hash, and find it >> on all path. So, all path will use same inode and lock. >> >> We need the key, possible key is - if it is only directory, FAT may be >> able to use i_start as additional search key. > > Interesting idea. I think this, and reformulating the FAT NFS file > handle to include the parent's i_ino, will greatly simplify (and speed > up) the code.
Does it work even if the inode was rename()'ed? -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
