lkml.org 
[lkml]   [2000]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: hfs support for blocksize != 512
Hi,

> Darnit, documentation on filesystem locking is there for purpose. First
> folks complain about its absence, then they don't bother to read the
> bloody thing once it is there. Furrfu...

It's great that it's there, but still doesn't tell you everything.

> Said that, handling of indirect blocks used to be badly b0rken on all
> normal filesystems and it had been fixed only on ext2, so I wouldn't be
> amazed if regular files were bad on B-tree style filesystems. Directories
> are easy - all requests are process-synchronous (no pageout), no
> truncate() in sight, so the life is better.

I don't think that files are that easy, at least from what I know now from
hfs. For example reading from a file might require a read from a btree
file (extent file), with what another file write can be busy with (e.g.
reordering the btree nodes).
I really would prefer that a fs could sleep _and_ can use semaphores,
that would keep locking simple, otherwise it gets only a fscking mess.

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.084 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site