Recurring corruption on HFS+ partitions?

exscape · 2014-12-22 18:24:39

I've been running Arch on my MacbookPro8,2 (Early 2011) for about 1.5 months now; most of my storage partitions are still HFS+. I'm running the stock Linux kernel from the Arch repos, so mostly 3.17.x kernels (currently 3.17.6-1-ARCH).

I disabled journaling on the two partitions that are mounted read/write, precisely to avoid corruption. However, bizarrely, it appears that some corruption has occurred even on a partition that I've never mounted as anything but read-only under Linux. I can't be sure the partition was actually corrupt, but reading from it showed major problems, at least (Nautilus refused to list files that worked the day before).

The symptoms I've noticed are mostly either "invalid argument" from random commands (I got plenty of that from git, until I moved my code to ext4), or that Nautilus simply refuses to show the contents of a folder.
dmesg is filled with hundreds of pages of output right now, stuff like:

[69443.933002] hfsplus: recoff 23130 too large
[69443.933006] hfsplus: request for non-existent node -251527168 in B*Tree
[69443.933007] hfsplus: request for non-existent node -251527168 in B*Tree
[69447.764928] hfsplus: recoff 23130 too large
[69447.764933] hfsplus: request for non-existent node -251527168 in B*Tree
[69447.764934] hfsplus: request for non-existent node -251527168 in B*Tree
[69447.953287] hfsplus: recoff 23130 too large
[69447.953292] hfsplus: request for non-existent node -251527168 in B*Tree
[69447.953293] hfsplus: request for non-existent node -251527168 in B*Tree
[69447.955210] hfsplus: recoff 23130 too large
... repeating with those exact numbers for a total of 3400 lines, all within a few seconds, then:
[78422.549262] hfsplus: recoff 25601 too large
[79941.634265] hfsplus: keylen 39132 too large
[80147.293544] hfsplus: keylen 26478 too large
[80152.346044] hfsplus: recoff 34760 too large
[80152.346074] hfsplus: recoff 54415 too large
[80152.346104] hfsplus: recoff 49167 too large

... and more stuff like that, at various times.
This has happened on both HFS+ partitions I've had as read/write (both with journaling disabled), *and* on one I've had as read-only the entire time, as I mentioned.

I doubt that there's a hardware problem, as I've had zero problems with this under OS X. I had some corruption that forced me to restore from backup almost 1.5 years ago, but besides that, I very rarely needed to fsck in OS X.
Also worth noting is that when running fsck (whether under Linux or from the OS X installer USB stick), it usually says the volume is OK -- even though it was broken prior to fsck, and worked again after...

Any ideas on what is going on? Anyone with similar experiences?
From what I've heard, the Linux HFS+ driver should be rather stable, as long as journaling is disabled.

Update: I noticed two page errors in dmesg as well... it might be memory corruption. Still weird that OS X shows no issues, and that my ext4 partition has also seemingly worked out perfectly.
Stranger yet, I tried to simply reboot -- and Steam went from telling me 14 files were corrupt (upon validating the game cache for HL2), to that all files were fine. The game didn't start prior to the reboot, but works fine now. There's definitely some sort of in-memory/in-kernel corruption, the question is whether it's caused by bad hardware or not.

Last edited by exscape (2014-12-22 18:55:34)

ANOKNUSA · 2014-12-22 22:08:32

From what I've heard, the Linux HFS+ driver should be rather stable, as long as journaling is disabled.

So it's only "stable" if you remove the safeguard against corruption? That seems rather odd, doesn't it?

If I were you, I'd keep those two worlds separate. Use Linux filesystems for Linux, Mac filesystems for Mac. Occasionally mounting an NTFS or HFS+ partition under Linux to move some files around is fine, but you shouldn't rely on it for critical storage. Linux doesn't really support Mac and Windows filesystems any more than the latter two support Linux filesystems.

exscape · 2014-12-23 08:25:10

ANOKNUSA wrote:

So it's only "stable" if you remove the safeguard against corruption? That seems rather odd, doesn't it?
If I were you, I'd keep those two worlds separate. Use Linux filesystems for Linux, Mac filesystems for Mac. Occasionally mounting an NTFS or HFS+ partition under Linux to move some files around is fine, but you shouldn't rely on it for critical storage. Linux doesn't really support Mac and Windows filesystems any more than the latter two support Linux filesystems.

Yeah, disabling journaling is clearly not great, but the kernel devs seem to feel that they haven't quite gotten the hang of writing to the journal without breaking it, yet. You have to mount with -o rw,force to mount such a FS read-write.

I'd like to keep them separate, but that's easier said than done at the moment. I have 4.7 TB of data on HFS+/NTFS partitions, and my only ext4 partition so far is 50 GB. :-)
I still have a bunch of problems in Linux that make me feel uncertain of whether I can keep running it or not, so converting everything seems a bit risky, as I'd have to convert back again later if I regret the switch.

FWIW, I tried running memtest86+ yesterday, but it keep either hanging (the "+" in memtest86+ kept blinking, but everything else froze) or rebooting literally after running 1 second. Not ONCE did it get to 2 seconds...
I realize that's an awfully bad sign of course, but the thing is, it does the same with other RAM, so it'd have to be the MB/CPU in that case. I also installed "memtester" under Arch to see whether memtest crashes because of hardware failure or something else (it might be peculiar on Mac hardware, for example), and so far it hasn't found any errors, and Linux still hasn't crashed.

WonderWoofy · 2014-12-24 03:44:04

Maybe you should give this a try?

Soukyuu · 2014-12-25 11:25:37

WonderWoofy wrote:

Maybe you should give this a try?

I used that one for NTFS back on the 3.14 kernels and it had issues if a torrent client was working with that partition. R/W was fast, but the partition "hanged" after a while so I had to remount it to make it work again. No corruption though. They have updated the driver for newer kernel some time after that, but I didn't test it anymore because I moved to native filesystems as ANOKNUSA suggests.

WonderWoofy · 2014-12-26 01:56:57

Native filesystems are always a better idea. I have never actually tried the Paragon driver, but I have seen it and heard that it works fairly well.

I wonder what torrent client you were using? Was it using preallocated extents? Btrfs had a similar issue a while back, so I wonder if ntfs with the paragon driver might do better with a torrent client that doesn't do preallocated extents...

Soukyuu · 2014-12-26 12:55:49

I used µtorrent via wine back then, and it didn't only freeze the paragon driver but caused my router to crash every few hours. Only found it out after switching back to ntfs-3g, don't ask me what happened there, I have no idea
Moved to ext4 + qBittorrent and had no problems since. The only reason why I was clinging to ntfs was because I had trust issues with linux because things broke or didn't work. So arch linux on that PC was a test run and I wanted to be able to return to windows if needed as painlessly as possible. That said, compared to other distros, the only breakages I had on arch linux so far were my fault, so it's here to stay.

Speaking of btrfs, I thought it was inherently a bad choice for torrent usage because of copy on write triggering every time you downloaded a piece?

WonderWoofy · 2014-12-26 20:03:42

Soukyuu wrote:

That said, compared to other distros, the only breakages I had on arch linux so far were my fault, so it's here to stay.

That is what I love about Arch. If it gets fucked up... it is because I fucked it up. But it also doesn't try to implement all kinds of non-upstreamed patches that cause more trouble than they are worth.

Speaking of btrfs, I thought it was inherently a bad choice for torrent usage because of copy on write triggering every time you downloaded a piece?

I think that what you are thinking of is actually the issues with the preallocated extents. I really haven't heard anything about that in a while actually, and even the systemd journal seems to be doing fine these days (also uses preallocated extents). I follow the btrfs mailing list, so while I don't read everything in it, I do get a fairly good idea of the issues that pop up with each kernel version.

Even so, you can still always issue a 'chattr +C /path/to/directory' to turn off CoW for that directory. This is what I was doing for /var/log/journal for a while until that problem went away. So you could definitely do this for whatever directory you download torrents to. You just have to be cautious because even if you turn off CoW, it will still do a kind of halfway CoW if you snapshot the directory. I don't know the details of how this works, but I have seen it mentioned on the mailing list a few times.

Arch Linux

#1 2014-12-22 18:24:39

Recurring corruption on HFS+ partitions?

#2 2014-12-22 22:08:32

Re: Recurring corruption on HFS+ partitions?

#3 2014-12-23 08:25:10

Re: Recurring corruption on HFS+ partitions?

#4 2014-12-24 03:44:04

Re: Recurring corruption on HFS+ partitions?

#5 2014-12-25 11:25:37

Re: Recurring corruption on HFS+ partitions?

#6 2014-12-26 01:56:57

Re: Recurring corruption on HFS+ partitions?

#7 2014-12-26 12:55:49

Re: Recurring corruption on HFS+ partitions?

#8 2014-12-26 20:03:42

Re: Recurring corruption on HFS+ partitions?

Board footer