Messages in this thread |  | | Date | Thu, 31 Aug 2000 17:36:37 +0200 (MET DST) | From | Roman Zippel <> | Subject | Re: hfs support for blocksize != 512 |
| |
Hi,
(Sorry for the previous empty mail, I was a bit too fast with sending and couldn't stop it completly.)
On Wed, 30 Aug 2000, Alexander Viro wrote:
I concentrate on the most interesting part:
> As for AFFS directory format - fine, please describe the data > manipulations required by unlink("foo"); done after the > link("foo","bar/baz");. Both operations are supported on AmigaOS, so > references to UNIX are utterly irrelevant. On the block level, please. > Only for directory blocks. Now, tell me what kind of protection (pageout > has nothing to directories, so all async problems are irrelevant) would > you provide. Or what protection should VFS/core kernel/exec/whatever > provide to filesystem.
Disclaimer: I know that the following doesn't match the current implementation, it's just how I would intuitively would do it:
- get dentry foo - get dentry baz - lock inode foo - mark dentry foo as deleted - getblk file header foo - mark file header foo as deleted - getblk file header baz - update file header baz from file header foo - brelse file header baz - update inode foo - unlock inode foo - put dentry baz - lock foo's parent - getblk and update dir header parent - getblk file headers from foo's chain until file header of predecessor of foo found - update predecessor to point to successor of foo - brelse everything - unlock foo's parent - put and invalidate dentry foo - last user of foo frees file header foo in bitmap
I probably forgot something, but you will surely tell me. Two things I want to mention anyway. First, I only lock something when needed, that of course breaks with current conventions. Second (and most important), I use the dentry to block a possible lookup of an inode, so noone can open or create foo or do anything else with it. A rename would work similiar only that the new dentry would be marked as not complete yet.
> On that specific operation. When you are done with > that, I have a rename() for you, but I think that even simpler example > (unlink()) will be sufficient.
Please post it, I know there are some interesting examples, but I don't have them at hand. Although I wanted to keep that flamewar for later, but if we're already in it...
> Again, we are talking about the data structure and operations it has to > deal with _according to its designers_. I claim that due to a bad data > structure design (single-linked lists in hash chains, requirement to have > all entries belonging to some chain) unlink() (one of the operations it > was designed to deal with) becomes very complicated and requires rather > hairy exclusion rules. On Amiga. Linux has nothing with the problem.
To be fair it shoud be mentioned, that links were added later to affs.
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/
|  |