Bug Description

Binary package hint: linux-686

Dapper Drake does not appear to support a HFS+ journaled file system. This manifests when I connect my ipod mini, and dmesg warns that:
'HFS+-fs: write access to a jounaled filesystem is not supported, use the force option at your own risk, mounting read-only.'
Using force appears to work to mount the device read/write. This was not a problem under Breezy, which makes me think that it's a kernel compilation issue.

I think in breezy we ignored the journal in hfsplus as long as the filesystem was clean. The module in dapper is new, and support for journaling is new. So this just seems to be a change in the way the module handles the case.

Are you certain that when you mounted it that the filesystem was clean?

I'm fairly sure the filesystem is clean - I also have a ibook, and checked it there using Disk Utility. I had a look at fsck_hfs too (on Mac), but that doesn't seem to work with a journaled file system. The problem seems consistant...

I'm pretty sure that Linux is able to read/write hfs+ partitions,
however it ignores the journalling (ie. it treats a hfs+ partition as
hfs). I have a feeling that Feisty removed the hfs functionality because
of instability fears. It may be that Gutsy has replaced it..?

Alternatively, you could recompile your kernel adding HFS support...

(I'm not very knowledgeable about this, so take it with a grain of salt
- I've reformatted my ipod to FAT ;-)

Good luck,
-Angus

ps. I was a little surprised to receive this email - I guess I've asked
a question somewhere..

On Wed, 2008-02-06 at 23:38 +0000, Davim wrote:
> Will we ever be able to read/write to hfs+ partitions??? this would be very important for many people...
> Are there any projects working on this??
>
> partedmagic (http://partedmagic.com/index.html) is able to create/resize
> journalled hfs+ partitions, why cant we do the same with Ubuntu???
>
> thanks,
> Luis Davim
>

I also get this on Jaunty, using linux-image-2.6.28-6-generic = 2.6.28-6.17

If I plug in an iPod, I am unable to write to it, even as root, and even though /etc/mtab marks it as rw. In dmesg, I see:

[21537.053625] hfs: write access to a journaled filesystem is not supported, use the force option at your own risk, mounting read-only.
[21538.614973] hfs: write access to a journaled filesystem is not supported, use the force option at your own risk, mounting read-only.
[21558.772508] hfs: filesystem is marked journaled, leaving read-only.

I have tried cleaning the disk, using fsck.hfsplus -r -f /dev/sdb3, which did fix some errors, but the problem remains. I cannot find any way to write to this iPod using Linux.

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux-image-`uname -r` 49052

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

Hi, thanks for your mail. I'm writting now with lastest version of Karmic in
live USB. Mac OSX partition is mounted in my desktop, but i only can read
it, so i can't write on it.
Can you fix this problem?

Tanks a lot in advance.

2009/6/24 kernel-janitor <email address hidden>

> Hi wallace-angus,
>
> This bug was reported a while ago and there hasn't been any activity in
> it recently. We were wondering if this is still an issue? Can you try
> with the latest development release of Ubuntu? ISO CD images are
> available from http://cdimage.ubuntu.com/releases/ .
>
> If it remains an issue, could you run the following command from a
> Terminal (Applications->Accessories->Terminal). It will automatically
> gather and attach updated debug information to this report.
>
> apport-collect -p linux-image-`uname -r` 49052
>
> Also, if you could test the latest upstream kernel available that would
> be great. It will allow additional upstream developers to examine the
> issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once
> you've tested the upstream kernel, please remove the 'needs-upstream-
> testing' tag. This can be done by clicking on the yellow pencil icon
> next to the tag located at the bottom of the bug description and
> deleting the 'needs-upstream-testing' text. Please let us know your
> results.
>
> Thanks in advance.
>
> [This is an automated message. Apologies if it has reached you
> inappropriately; please just reply to this message indicating so.]
>
>
> ** Tags added: needs-kernel-logs
>
> ** Tags added: needs-upstream-testing
>
> ** Tags added: kj-triage
>
> ** Changed in: linux (Ubuntu)
> Status: New => Incomplete
>
> --
> no hfs+ journal support
> https://bugs.launchpad.net/bugs/49052
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

@laelfrog: this bug is not Ubuntu-specific at all; the author of the code (Roman ZIppel) probably wrote that warning because he was not sure that the code is safe when writing on a journaled partition. The problem is writing on the journal - you can disable journaling on the FS, which decreases the resilience to crashes. According to [1], it can be done from Mac OS X with this command (which I didn't try):
diskutil disableJournal /Volumes/TheVolumeName

it is unlikely that Ubuntu works on this - in the very best and unlikely case, they could sponsor some external developer to fix it. The author of the code is Roman Zippel, and git log fs/hfsplus shows that he has not worked on it actively at least since 9 Apr 2008 [2]. And the driver does not support filesystems bigger than 2TB because nobody has a week (at most) to spend on changing the type used for sector numbers :-( (see git history of fs/hfsplus, on git.kernel.org).

AFAIK, the hfsplus driver hasn't been updated since 2 years (the
developer didn't work on it since), so I guess we're still stuck with
read-only HFS+, or forced to disable journalling on the HFS filesys

I think it would be very worth it to spend some effort on this--currently the only journalled filesystem writable by all three major OSes is NTFS. If we could have this on Linux, it would make for a second one. (and one that's slightly unix-friendlier)

I have no idea why this was marked as implemented because it isn't. Also I don't know why they aren't mounted read/write non-journeled by default in light of Apple's own documentation at http://support.apple.com/kb/ht2355:
"Journaled file system is part of a set of incremental enhancements to the Mac OS Extended file system, and it is backward compatible with the Mac OS Extended file system. Users can read, write, and access journaled Mac OS Extended volumes on computers that do not have a journaling feature."

I have no idea why this was marked as implemented because it isn't. Also I don't know why they aren't mounted read/write non-journeled by default in light of Apple's own documentation at support.apple.com/kb/ht2355:
"Journaled file system is part of a set of incremental enhancements to the Mac OS Extended file system, and it is backward compatible with the Mac OS Extended file system. Users can read, write, and access journaled Mac OS Extended volumes on computers that do not have a journaling feature."

This patch does not implement journaling but switches the driver to mount such volumes read/write by default. As Apple's own documentation explicitly states there is no danger in this beyond what is created by disabling journaling.

@michael -- changing that default sounds pretty dangerous to me, I note that using the force option you can override this an mount them if you wish; which seems like an appropriate default to me. Is there a reason that this is not acceptable? The kernel team is unlikely to be happy changing that default across the board without some buyin and agreement that this is an appropriate change from upstream maintainers. It might be appropriate to start an email thread with them and see if they concur.

@Andy Whitcroft Now that I'm thinking about it I don't know why I changed it in the first place. I'm going to get in touch with the upstream maintain about actually getting journaled hfsplus support implemented. Where can I find contact information?

I actually haven't been doing much with it. I have started putting code in place to at least tell if the journal is empty or not. This would be the first step. I'll put up a code patch for this first. I haven't yet read the specs for actually recording and re-playing transactions. The fallowing files need to be permanently hidden on journaled hfsplus ".journal_info_block" and ".journal" as they contain the journal itself. I don't know where to do this though.

Good to know Michael. This could be a pretty huge feature for Mac converts who want to test out the waters. I have a bunch of Mac drives I used for lots of stuff over the past 3-4 years and as a former mac user, that was my strategy. I have since switched full on to Ubuntu and am planning on migrating all data to EXT4 however I am sure there are many Mac users in the same boat.

I have working test driver that can detect an empty journal on mount read/write in this case but without journaling support. I also found complete but not yet fully tested code for fully supporting hfs+ journaling http://comments.gmane.org/gmane.linux.file-systems/56609. I haven't even compiled this code yet.

I have upload source code to https://code.launchpad.net/~reeves-87/+junk/hfsplus-dkms. It does not currently journal the drive once its mounted but will init/replay the existing journal as needed. The mount is read/write by default. The source has support for dkms but should as part of the kernel source tree.

I would be able to test it if you make oneiric packages, I installed the one for precise in your ppa and it still wouldn't mount rw (even after a restart and trying to mount it using the mount command).

Quantal and oneiric can now build the dkms module. The kernel version is detected at compile time using #if conditions the adjust for abi changes. All users of the module also get driver support for blessing hfs+ volumes to mark them bootable. This was intruded by mainline in kernel 3.5. The new version actually turns journaling on which was not previously the case. As included is a patch to attempt fix write issues on drives > 2TB. The patches were discussed here: http://www.spinics.net/lists/linux-fsdevel/msg42242.html. I don't know if they've been tested before and cannot test them myself. Please report any bugs you find.

I've have created a project page at https://launchpad.net/hfsplusdkms release notes and source tar balls will be posted there. Please report issues there. Also the package for precise should work for quantal and oneiric as well.

Actually the driver for this is ready for testing. If there's no issues I'm
going to see about getting the code into the kernel. Currently this is a
dkms module with its own repository. At https://launchpad.net/hfsplusdkms.
It should work with kernel 3.0-3.8

On May 14, 2013 10:06 AM, "Ali" <email address hidden> wrote:
>
> Does it support writing a journal or does it still deactivate journaling
> after replaying?
>

It has full read/write support for journaling. I updated the code from an
abandoned project to work with the new kernel ABI. Don't remember who was
working on it but journaling support is complete in the code. I use this
module myself as I have a Macbook Pro. No troubles with it as far as I've
seen. Just want to make sure this works on other systems besides mine.

Its reasonably stable only journaling aspects are different from mainline. Also I have attempted to fix problems with drivers bigger than four TB the would result in corruption of the file system. The fix came from an a proposal the upstream mailing list a while back not sure where things went from there. Run apple's disk utility after using either feature. In the case of large drives it should never find issues. For journaling the results should be similar to what you get when OS X replays the journal. I have it use on my machine.

Just updated for kernel 3.11 api I should be uploading new packing within
the week. These are actually source packages which dkms compiles and
installs. Any system with at least kernel 3.2 should be able to use any
package.