>> 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/