lkml.org 
[lkml]   [2000]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.083 / U:0.256 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site