Opened 10 years ago

Closed 9 years ago

#11289 closed bug (fixed)

Invalid b+tree filesystem corruption on hrev47914

Reported by: Atarian Owned by: axeld
Priority: normal Milestone: R1
Component: File Systems/BFS Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by luroh)

Install works fine, any disk access results in corruption, which prevents boot with a kernel panic sometimes. checkfs from another haiku partition fixes it temporarily.

Change History (4)

comment:1 by waddlesplash, 10 years ago

Component: - GeneralFile Systems/BFS
Owner: changed from nobody to axeld

Please attach syslog, listdev, and any other info you might have (e.g. what you were doing with the disk, how large the partition was, etc.).

in reply to:  1 ; comment:2 by Atarian, 10 years ago

Replying to waddlesplash:

Please attach syslog, listdev, and any other info you might have (e.g. what you were doing with the disk, how large the partition was, etc.).

Unfortunately, I cannot attach any further data as WebPositive is broken in this build and netsurf doesn't appear to allow file uploading, or allow CRs in the comment fields. The partition is 300mb BeFS fresh install of the nightly.

Creating any new file (by downloading from the web or using wget) appears to cause this.

Last edited 10 years ago by Atarian (previous) (diff)

in reply to:  2 comment:3 by luroh, 10 years ago

Description: modified (diff)

Replying to Atarian:

The partition is 300mb BeFS fresh install of the nightly.

300 MB is tight. See if a bigger partition helps.

Last edited 10 years ago by luroh (previous) (diff)

comment:4 by mmlr, 9 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev48059. The invalid b+tree messages were harmless false positives caused by a missed special case in a check during b+tree validation. They didn't cause actual FS corruption and were not indicative of existing problems. They may however have hidden actual b+tree problems that would have been checked further down the validation path.

In any case, this did not affect the filesystem operation, so can't be the cause of panics on boot. If you encounter these again, please create a new ticket with the info suggested above. Getting more infos about actual filesystem corruption would be greatly appreciated.

Note: See TracTickets for help on using tickets.