Messages in this thread |  | | Date | Thu, 31 Aug 2000 21:44:32 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: hfs support for blocksize != 512 |
| |
[snip the plans for AFFS]
You know what? Try it. If your scheme is doable at all (I _very_ seriously doubt it, since I've seen similar attempts on FAT-derived filesystems and I remember very well what horror it was) it is doable with private locks. Just take your locks always after the VFS is done with getting its locks and you can forget about the locking done in VFS - the only effect will be that you will see (possibly) fewer simultaneous calls. Which should reduce the pressure on your mechanisms, so if they can work by theselves - they will work.
Go ahead, write it. IMNSHO it's going to be much more complicated and race-prone, but code talks. If you will manage to write it in clear and race-free way - fine. Frankly, I don't believe that it's doable.
Several things to watch for: * opened unlinked files should remain available until the last process closes the file. * if foo and bar exist there should be no interval during the rename(foo, bar) when open(bar,...) would fail. * busy directories can be removed. * ... and that includes rename() over them. * large intervals when power-off would lead to unrecoverable fs are bad. I'm not talking about full protection, but several seconds of inactivity (i.e. no new requests being submitted) should be enough even on floppies. You will get dirty fs, indeed, but it shouldn't be in catastrophically bad state.
BTW, I really wonder what kind of locks are you going to have on _blocks_ (you've mentioned that, unless I've misparsed what you've said). IMO that way lies the horror, but hey, code talks.
Right now the thing doesn't even work reliably. If you claim that your design will reduce the contention if VFS will get out of the way - better yet, but let's see first if it will work and will be readable.
Allocation problems are not going to enter the game - on AFFS you've got no sparse files and thus all allocation is process-synchronous. Moreover, you can count on the fact that truncate and allocation attempts on a file are not going to clash (that includes the lack of clashes between allocations).
You claim that it's doable. I seriously doubt it. Nobody knows your ideas better than you do, so... come on, demonstrate the patch.
- 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/
|  |