"Steven J. Magnani" <[email protected]> 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 <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
