[haiku-development] Re: Filesystem corruption and Alpha-1
- From: David McPaul <dlmcpaul@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 24 Jun 2009 08:52:10 +1000
2009/6/23 Stephan Assmus <superstippi@xxxxxx>
>
> Hi everyone,
>
> with this e-mail, I want to initiate some feedback in two directions. First
> of all, I want to gauge other peoples general experience with file system
> corruption. Secondly, I want to steer up some discussion with regards to
> filesystem corruption preventing the release of Haiku Alpha-1.
>
> I am aware of perhaps three different types of unresolved file system
> corruption. One is the sudden transformation of a volume into read-only
> mode. I have not seen it myself, but Matt just recently opened a ticket for
> it. Another one is the report of file system corruption after copy
> operations. We have an open ticket for it in the Alpha-1 milestone. But we
> don't know if this bug may have been resolved by Axel's recent filesystem
> fix. The third issue is one which I experience myself when retrieving
> mails. From time to time, several of my mail folders go back to a certain
> number of mails, the rest of them just disappears. Even though Axel gave me
> several clues as to what would be helpful information to retrieve, I have
> not yet begun to poke at it harder, mostly because it's reproducable
> eventually and has not bothered me enough yet. Plus we are going to meet
> soon and can hopefully track it down then.
>
> Anyway, what's the general impression of other people, is anyone seeing
> something else frequently? Or none of these things at all? If you see any
> of these issues, how often?
I had the filesystem going read only on me bug quite regularly when
writing large files to disk. Since updating to the latest revision
this no longer occurs.
I have never had files disappear.
I have had files refuse to delete via tracker.
> My second line of thought is this: We have promised to fix all known
> filesystem bugs before we want to release R1/Alpha-1. But, even once we
> managed to fix all /known/ bugs, isn't there a good chance that one or more
> bugs still remain uncovered? In any case -- we do not want testers of our
> Alpha-1 release to fully trust it. What is better: "We fixed all file
> system corruption issues known to us, but please make backups of important
> data anyways!" Or "There are at least three known bugs that cause
> filesystem corruption. They do not happen frequently enough to make working
> on Haiku impossible, but they do happen so please be sure to make frequent
> backups of important data." Hm. What is more likely to make users do
> backups?
A big warning requester on first boot?
> Another open issue of the Alpha-1 milestone is the ATA bus_manager. I've
> tried to help a bit with that, but to be honest, I don't really know what
> the remaining issues are. Why have we not yet switched over to it? If more
> systems work with the ATA bus_manager, now, wouldn't it be the natural
> consequence to make the switch right now? If systems that worked before
> stop working, we could still offer the old IDE bus_manager in the build,
> just like we offer the ATA stack right now for people who can do their own
> builds. Maybe a switch would increase the pressure to fix remaining issues
> in the ATA stack.
I have switched over to the ATA bus manager without issue, so I am
fine with making it the default.
I have been using Haiku to develop Haiku on which has made things go a
lot quicker in the code-build-test cycle.
My outstanding issues to make Haiku work best for me are:
1. checkfs won't run because 1 partition is not recognised or
something (I cannot format a partition either)
2. when copying directories the destination uses more disk space than
the source. 500Mb turns into 1.5Gb
3. Intel extreme driver does not work for me.
4. no source level debugger
I threw the last one in because I know it is being worked on :-)
If you are expecting to release BFS with known or unknown errors then
I think having checkfs work on a partition regardless of the state of
other partitions is a good idea I think.
The copying of files between partitions can be worked around and the
intel extreme issue I drop back to VESA mode.
So...+1 on ATA switch.
--
Cheers
David
Other related posts:
