Hi,
On Mon, 13 Mar 2000 16:19:39 +0100, Jamie Lokier
<lfs@tantalophile.demon.co.uk> said:
> Alex Viro's concerns are not about whether reiserfs passes stress
> tests. They're about subtle, and not to subtle deadlock, livelock and
> race conditions, and long term maintainability.
That's certainly part of it.
For true production-quality robustness, there are a whole pile of things
which need to be dealt with which aren't necessarily perfected just by
getting stress tests running reliably. It might be useful to get a
check-list of things which are easy to overlook. As a first attempt,
I'd include:
* Locking
This has already been mentioned. 'Nuff said.
* Fault handling
The filesystem must respond cleanly to *all* out-of-memory failures
and media EIO errors. The response to ENOMEM may be to spin
waiting for memory, and EIO may take the filesystem offline, but in
either case when control returns to user space the filesystem must
be in a known state in which all resources used by that syscall are
released and the filesystem can be unmounted.
The bad_inode stuff is particularly useful for handling "I can't go
any further!" EIO failures, and in the worst case, ENOMEM can always
result in a panic: the admin can set a reboot-on-panic timeout so if
things go unrecoverably wrong, we at least get an automatic clean
boot out of it.
* fsck.
This is something Ted has been very good about: there is a
comprehensive regression suite in e2fsprogs to test not only
recovery from normal situations on the disk, but also to recover
from all manner of corruptions which cannot occur in the normal
running of the filesystem but which happen when memory goes bad,
media fails, the user runs fsck on a mounted partition and then ^Cs
it, or whatever. There should be no combination of on-disk
conditions which should allow fsck to crash, even though some forms
of corruption won't let you recover much of any value!
* Scaling up
Cache management and writeback policies need to be tested and proven
on very, very big boxes.
* Scaling down
Cache management and writeback policies need to be tested and proven
on very, very small boxes. :-)
If you deadlock when running half a dozen filesystems on a 16MB box,
something is wrong. I think we need extra VM infrastructure to deal
reliably with this: both ext3 and reiserfs will be hurt by the need
to build whole transactions before committing stuff to disk, as we
may run out of memory mid-transaction while the rest of the
transaction is still pinned.
Just a few thoughts: it's probably useful to keep a checklist like this
in mind as we bring new filesystems into the mainstream. Anything I've
missed?
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:21 EST