Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#7783 closed bug (invalid)

BFS fails to 'sync' at Shutdown, resulting in tracker_shelf ..etc corruption

Reported by: ttcoder Owned by: nobody
Priority: normal Milestone: R1
Component: System Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Will put the bulk of the info I have in some separate comments below, to benefit from the "edit to correct my dumb typos" feature, which is not present for the initial ticket description (this Description here only has a "Reply" button, no "Edit" button even when logged in).

See #5262 for my initial comments (and ticket drift, oops)

Change History (4)

comment:1 by ttcoder, 13 years ago

Well looks like this ticket won't be updated any more and can be closed.. I'm writing this from another computer -- the HDD on my Haiku computer has just crashed (harddrive not even detected by the BIOS) together with the draft of what I meant to insert here -- not that this matters now.. At any rate it's the second HDD I lose while testing Haiku. Not that they were new or anything, but I'll investigate #6847 just in case it's the culprit :-(

comment:2 by anevilyak, 13 years ago

Resolution: invalid
Status: newclosed

comment:3 by tonestone57, 13 years ago

@devs
I still think very good idea to make sure the disk cache is flushed before shutting down the OS like Michael said. That should avoid any filesystem corruption happening from Haiku itself.

@ttcoder
From other ticket, I believe you have:
KERN: ata 0-0: model number: Maxtor 6L250R0
KERN: ata 0-0: firmware rev.: BAH41G10

Maxtor was bought by Seagate. I see no firmware updates for your drive but maybe buggy firmware. You should still test with SeaTools DOS (short & long tests) and maybe can get access to the drive to get it working again. Play around in BIOS, try auto detection and manual, look at spec sheet confirm drive info I give below. Try changing some of the other drive settings too. SeaTools may also see the drive without the BIOS so try that out too.

http://www.seagate.com/ww/v/index.jsp?locale=en-US&name=SeaTools&vgnextoid=720bd20cacdec010VgnVCM100000dd04090aRCRD

I have seen few others mention bad sectors and drive failing on these models in the last year. The early, high capacity drives had issues and were more likely to fail. That reboot/power button trick may have also caused problems to your drive causing it to fail sooner.

MODEL    ACT CYLS  HDS:SECT  MAX CYLS   MAXLBA     GB CAPACITY
6L250R0  486,344    16:63     16,383  490,234,752    250GB

in reply to:  3 comment:4 by ttcoder, 13 years ago

Replying to tonestone57:

@ttcoder
From other ticket, I believe you have:
KERN: ata 0-0: model number: Maxtor 6L250R0
KERN: ata 0-0: firmware rev.: BAH41G10

Good digging for info ;-) Yes this and the info below look correct.. It is/was a DiamondMax 10.. Shame you had to do some duplicate research effort due to my losing data.. Something else to mention while it's fresh in my mind: in the last couple days the syslog became a little crazy (which added urgency for me to post the ticket) with some errors like "ata: PIO timeout" or "ata: sense failed" and "ata incorrect sense code 0x74" and the such.. Even with an idle OS, not touching the kbd or mouse, the syslog grew steadibly by about 50 bytes/second... Not a single hint of BFS corruption though, as I had disabled ACPI so as to get the "you may now [force] shutdown your computer" window. The swan song was a few seconds before it died for good, as I started getting some (recoverable) KDLs with message "timeout on write", then the last one before I rebooted to the now-empty BIOS was "timeout on read".

Maxtor was bought by Seagate. I see no firmware updates for your drive but maybe buggy firmware. You should still test with SeaTools DOS (short & long tests) and maybe can get access to the drive

Thanks for all the good info; will install XP again to another hard-drive, and try all this. Anyway I had mostly redundant (or non valuable) data on that drive, except for a couple changes to soundplayTT but I can do them again from memory.

That reboot/power button trick may have also caused problems to your drive causing it to fail sooner.

Woah. If I'm ever forced to use the trick again I'll be sure to ask around about how safe/unsafe it is :-).. I'm guessing OS'es (Haiku ..etc) do some particular operations that the ATX tower switch itself does not do..? Back in BeOS days we had little ACPI to speak of so most of us had to force-shutdown probably, but on the other hand HDDs were most likely more robust than these days.

In closing, I have to take back my "sad face" comment.. True, I have never 'lost' an HDD to another OS (but my BeOS drives are old robust dinosaurs).. But for as much as I found it suspicious to lose 2 HDDs in Haiku, the evidence works against this suspicion: the first HDD with hrev39648, a WD200 Caviar dates from 2002 and I got it on a flea market, history unknown (!).. And the Maxtor with hrev41848 was given to me as part of a 4-way RAID array that worked intensely since 2005 apparently.. I know little about RAID except that if they all wrote the same data at the same time and have similar MTBFs then I can expect the other 3 Maxtors to fail after the same (or similar) time elapsed.. Will be careful with those.. So no reason for being grumpy here it seems. Now if I lose a third HDD of another brand and newer condition, you know you'll hear from me ;-)

Note: See TracTickets for help on using tickets.