Ext3 500GB HDD mounted only as read-only

[MichaelPeppers]

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)

[korli]

Please indicate the revision used.

[MichaelPeppers]

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.

[korli]

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.

[MichaelPeppers]

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)

[korli]

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.

[MichaelPeppers]

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)

[korli]

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?

[MichaelPeppers]

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.

[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 ?

[MichaelPeppers]

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.

[MichaelPeppers]

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)

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone