From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <84f87acc73d5e1d4957a925d15768704@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] boot error walking From: Charles Forsyth In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 14 Feb 2004 16:00:42 +0000 Topicbox-Message-UUID: e3c0730e-eacc-11e9-9e20-41e7f4b1d025 >>effects, recovery is comprehensible and complete, and finally improper >>operation (e.g. letting the disk fill up) should not result in an >>unbootable machine. ... it has a long way to go to equal >>what I'm used to in the Unix/Linux world. i must be imagining that my Linux partition is currently unbootable because it filled up and resulted in an unbootable partition. oh all right, i can boot it but it can't start up properly. fortunately, i can still boot the machine with something else. still, i remember that you were also lucky with IBM's AIX/JFS recovery, which they appear to have debugged some time after i used it! i'm generally fairly lucky myself, but not those times. >>I keep wondering if the kinds of >>guarantees on I/O ordering that a file system needs for its activities can >>be met outside a kernel? .. i'm not sure i see why not. for instance it could write "keep off" into a ctl file to stop re-ordering (not that i think the kernel does), or to get the sd*.c to signal the drive to stop re-ordering. fossil itself was supposed to fuss quite a bit in the soft update style to get the resulting order right (if the drive doesn't muck it up). i'm currently a bit less worried about crash on power failure/off than i am about software bugs, and i had the impression we had some of the latter in at least one of fossil or venti. (i'd prefer it to be venti because it's logically simpler, but i did find and fix something in fossil before. admittedly it was along the lines of a statement that could have had a comment ``yes, the bug is here'' because it stood out so much, so that was easy.)