Messages in this thread | | | Date | Sun, 17 Jan 1999 15:27:14 +0000 (GMT) | From | Riley Williams <> | Subject | Re: [RFC] What should we do with FAT inode numbers? |
| |
Hi Albert.
>> Alternately - use the dir entry coordinates but maintain that >> while the inode is open. The cached data should include the >> "new inode number" which is different from the used ino if the >> file was renamed or unlinked while it was open. If an open file >> was deleted/renamed and a new file was created using the same slot, >> a temporary inode number can be allocated for the new file (and >> maintained while this new file is open).
> This does the job well:
> 1. except for rename, inodes on disk are long-term stable > 2. inodes are stable for open files, even when renamed
> With "open" meaning any process on the system and "inode number" > being what is reported to normal processes, the rules are:
> 1. Inodes are dir entry coordinates. > 2. After rename, inode numbers change as soon as the file is not > open. > 3. If a new file gets a slot that gives it an inode which conflicts > with the reported inode of an open file, report something else > (really _anything_ else) until both files are no longer open.
> Compared to silly_rename this is clean and easy, but it does leave > a larger (infinite vs. milliseconds) window during which a crash > would leave lost clusters.
I havenae been following this thread much, so I'm probably well off-base here as a result, but surely, the obvious solution to this is simply NOT to reuse a directory entry for an unlinked file whilst the said file is still open?
If so, then all that appears to be required to deal with this situation is an algorithm similar to the following pseudocode for selecting the entry to be used for a file that's new to that directory (either because it's been newly created or because it's been moved from another directory in the partition):
Q> Deleted = 0 Q> Ptr => First entry in directory Q> repeat Q> Case Ptr->Name[0] in Q> 0x00: // End of entries marker // Q> If Inode(Ptr) found in list of open files then Q> // Can't step over 0x00 entry, so change // Q> // it to 0xE5 entry instead, and treat // Q> // as if it had been such to start with // Q> Ptr->Name[0] = 0xE5 Q> Deleted += 1 Q> OK = False Q> Else Q> OK = True Q> EndIf Q> Break Q> 0xE5: // Entry marked deleted // Q> If Inode(Ptr) found in list of open files then Q> Deleted += 1 Q> OK = False Q> Else Q> OK = True Q> EndIf Q> Break Q> other: // Entry still in use // Q> OK = False Q> Break Q> EndCase Q> If not OK then Q> If Ptr is the last physical entry in the directory then Q> If this directory can be extended then Q> Extend this directory Q> Ptr => Ptr->Next Q> // Since we've only just created this entry, // Q> // it must be available for use, so... // Q> OK = True Q> Else Q> If Deleted > 0 then Q> // ******************** // Q> // *** COMPLICATION *** // Q> // ******************** // Q> Else Q> ERROR "Directory Full" Q> EndIf Q> EndIf Q> Else Q> Ptr => Ptr->Next Q> EndIf Q> EndIf Q> until OK Q> NewEntry = Inode(Ptr)
The only complication I can see occurs at the point indicated, at which point the following are all true:
1. We are dealing with a directory that can't be extended (probably because it's the root directory of that partition).
2. Every entry in that directory is either occupied or refers to a file that's been unlinked, but is still in use.
3. There is at least one entry that has been unlinked, but is still in use.
In these circumstances, it would in my opinion be WRONG to report that the directory is full since there is at least one entry therein that we could use, and that's the real problem that needs to be dealt with.
In the case that the only references to entries in this directory all refer to deleted entries, a simple solution would be to change the range of inode numbers that refer to entries in that directory, in which case the whole problem vanishes. However, that only deals with a subset of the problem cases, and probably a small subset at that, and it also requires the driver to be able to remap ranges of inode numbers on request...
Other than that, I can see the following possible solution to this complication, but I can also see the capability of causing other problems that it has:
1. Insist that if we unlink an entry in such a directory when it's still in use, we change the inode thereof to point to an unused entry in an extensible directory.
Best wishes from Riley.
--- * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/~rhw/kernel.versions.html
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |