Opened 6 years ago

Closed 8 weeks ago

#10194 closed bug (fixed)

Ext3 500GB HDD mounted only as read-only

Reported by: MichaelPeppers Owned by: korli
Priority: normal Milestone: R1
Component: File Systems/ext2 Version: R1/Development
Keywords: ext3 read-only Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by korli)

As the title says, everytime I'm trying to mount this Harddisk in R/W mode it silently fails then Haiku proceeds to mount it as read-only. Syslog only says this:

KERN: [34mext2:[0m Inode::EnableFileCache(): Failed to create file cache
KERN: [34mext2:[0m AllocationBlockGroup(226,7405568)::Initialize(): Mismatch between counted free blocks (16375/32768) and what is set on the group descriptor (0)
KERN: [34mext2:[0m could not initialize block allocator, going read-only!

On every other system I use this HDD (Win XP, Linux Mint Debian) it works in R/W mode just fine (StyledEdit is not showing some characters on these lines by the way)

Attachments (1)

dumpe2fslog.txt (3.7 MB ) - added by MichaelPeppers 6 years ago.
Here it is, the log is really big and... partly in italian (all of the translated terms are actually pretty similar to their english counterparts so I think you should still be able to read them)

Change History (12)

comment:1 by korli, 6 years ago

Description: modified (diff)

Please indicate the revision used.

comment:2 by MichaelPeppers, 6 years ago

hrev46335, I've seen some work done in the source on the ext2 driver yesterday, so I'll test this out again soon with a newer revision.

comment:3 by korli, 6 years ago

Please install e2fsprogs on your Linux and provide the output of "dumpe2fs /dev/sdaX" with /dev/sdaX as your disk partition. Thanks!

The blockgroup 226 doesn't seem to have the uninit_bg feature enabled, so it stopped with this inconsistency. The dumpe2fs output should tell what's the truth here.

by MichaelPeppers, 6 years ago

Attachment: dumpe2fslog.txt added

Here it is, the log is really big and... partly in italian (all of the translated terms are actually pretty similar to their english counterparts so I think you should still be able to read them)

comment:4 by korli, 6 years ago

Thanks for the output. It looks like it is the same value Gruppo 226, 0 free blocks.

I would suggest a fsck to be sure with the consistency (even if it seems it was run one week ago). Also be aware that mounting read-write an ext2/3/4 partition in Haiku is not risk free.

comment:5 by MichaelPeppers, 6 years ago

Well, fsck *does* say there are some consistency errors in the disk, likely caused by the driver used by Win XP (but those should be something minor since it works perfectly fine, I guess the bootup scan doesn't take care of those) Fact is, even with errors inside the disk, Haiku should be able to mount it as read/write anyway imo, maybe bringing up a warning or something beforehand, as the disk works afterall. And yes, I know the Haiku driver is not perfect, but there are some use cases where I'd need to access it from my Haiku install (say, my Linux install gets busted *again* and I need to edit some file in there quick, so no XP). There's already a prompt warning that it may be unsafe but if I'm willing to take the risk I'm fine with the occasional error... or even data loss. (to a certain extent ofc)

comment:6 by korli, 6 years ago

I understand your concern, it's a tough choice though. Letting the user mount read/write could corrupt the all filesystem ... or not... I suppose we could add a "force mount read-write" option and let a power user live with the risk.

Is fsck actually able to fix these errors anyway?

in reply to:  6 ; comment:7 by MichaelPeppers, 6 years ago

Replying to korli:

I suppose we could add a "force mount read-write" option and let a power user live with the risk.

Please do, users should be in control of what the system can do, even if it can prove harmful. After a warning and having to force such a behavior if anything goes south the user can only blame himself for trying anyway, or at least that's how I see it.

Is fsck actually able to fix these errors anyway?

Yes, but not on "automatic fix" mode, so I'd have to hold "y" for like half an hour to take care of those.

in reply to:  7 ; comment:8 by anevilyak, 6 years ago

Replying to MichaelPeppers:

Yes, but not on "automatic fix" mode, so I'd have to hold "y" for like half an hour to take care of those.

By "automatic fix" mode, do you mean fsck -y ?

in reply to:  8 comment:9 by MichaelPeppers, 6 years ago

Replying to anevilyak:

Replying to MichaelPeppers:

Yes, but not on "automatic fix" mode, so I'd have to hold "y" for like half an hour to take care of those.

By "automatic fix" mode, do you mean fsck -y ?

Ooh, I missed that option, I was using fsck -p actually. Gotta try that later, thanks for the tip.

comment:10 by MichaelPeppers, 6 years ago

The filesystem has been fixed now, mounting it as read-write takes a lot of time but it seems to work. As such I can't provide further feedback about the original issue. (which was about mounting in RW a damaged ext3 partition)

comment:11 by waddlesplash, 8 weeks ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.