Hi,
> > - get dentry foo
> > - get dentry baz
>
> How? OK, you've found block of baz. You know the name, all right.
Links are chained together and all point back to the original, so if you
remove the original, you have quite something to do with lots of links.
> Now
> you've got to do the full tracing all the way back to root.
All file header have a pointer to the dir header, so it's not that
difficult, but that makes links to directories so interesting. :)
Anyway, I'll better try to describe the idea more generally:
The basic idea is to introduce transient states to vfs and to move the
locking into the fs, which probably knows better what needs to be
protected. This would avoid the current locking overkill. Let's take a
rename, first we mark the object as to be moved, no need to keep it locked
after this. An open on this object would either fail or had to wait (on a
seperate queue). Next we mark the destination dir as not removable. This
is basically the job of vfs so far, the next steps happen in the fs.
(I use affs here as an example.) First we lock the source dir and
remove the object from the chain and unlock the dir. Now I can lock the
destination, insert the object here and unlock the dir. (back to vfs) All
we have to do now is to restore now the state of destination dir and the
object and we have to wakeup anyone who's waiting.
Back to the original example of removing a file with links. I have to get
the dentry of baz as I have to prevent a lookup of that link, while I'm
modifying its block. But I think it's enough to lock that block and check
only the cached aliases. Then I can modify that block and unlock it again.
> > - update file header baz from file header foo
>
> If it would be that simple... Extent blocks refer to foo, unfortunately.
> Yes, copying the thing would be easier. Too bad, data structure prohibits
> that.
Which data structure prohibits that?
Updating the extent blocks isn't that difficult as the back links are not
needed for general operation, it's just wasting I/O. A bit more
problematic are concurrent readers of foo, so I can't simply trash the
buffer of foo's file header, but I can simply keep it allocated till the
file is closed (keeps also the inode number constant and unique).
> Well, consider rename over the primary link and there you go... Keep in
> mind that extent blocks contain the reference to header block, so unless
> you want to update them all you've got to move the header into donor's
> chain ;-/
Oops, I just read rename(2) and notice that I forgot about a small detail.
Ok, above rename operation get's slightly more difficult. Basically it's
only a variation of the unlink problem, I first unlink the old file and
then insert the new file. As I do less locking, I shouldn't have a
locking problem or what do I miss? I just might have to update lots of
back links, but that is not a critical part.
[I can skip the affs history part, I just see you already got a better
answer than I could give.]
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:28 EST