[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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:29 EST