All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rogério Brito" <rbrito@ime.usp.br>
To: Matt Mackall <mpm@selenic.com>
Cc: zippel@linux-m68k.org, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Serious problems with HFS+
Date: Mon, 14 Mar 2005 00:23:03 -0300	[thread overview]
Message-ID: <20050314032303.GA29808@ime.usp.br> (raw)
In-Reply-To: <20050313203604.GF3163@waste.org>

On Mar 13 2005, Matt Mackall wrote:
> I've noticed a few problems with HFS+ support in recent kernels on
> another user's machine running Ubuntu (Warty) running 2.6.8.1-3-powerpc.

I also saw some of the things that you reported with Debian proper (sarge).
Unfortunately, I haven't been able to use my HFS+ formatted system with
Linux for a while, I may do so, if necessary to fix the bugs.

> I'm not in a position to extensively test or fix either of these problem
> because of the fs tools situation so I'm just passing this on.

I, OTOH, can test fixes on the next weekend, since I have a full backup
scheduled for this week.

> First, it reports inappropriate blocks to stat(2). It uses 4096 byte
> blocks rather than 512 byte blocks which stat callers are expecting.
> This seriously confuses du(1) (and me, for a bit). Looks like it may
> be forgetting to set s_blocksize_bits.

I had not noticed what are the size of the blocks that HFS+ seems to use,
but indeed I saw both very confused du and ls outputs. I don't know what
may be the cause.

> Second, if an HFS+ filesystem mounted via Firewire or USB becomes
> detached, the filesystem appears to continue working just fine.

That's the only way that I am using a HFS+ fs (fia Firewire or USB), since
the drive in question is in an enclosure.

> I can find on the entire tree, despite memory pressure. I can even create
> new files that continue to appear in directory listings! Writes to
> such files succeed (they're async, of course) and the typical app is
> none the wiser. It's only when apps attempt to read later that they
> encounter problems. It turns out that various apps including scp
> ignore IO errors on read and silently copy zero-filled files to the
> destination. So I got this report as "why aren't the pictures I took
> off my camera visible on my website?"

I haven't seen this behaviour for lack of testing, but I will try to
reproduce it with an HFS+ fs on a file mounted via loopback.

> This is obviously a really nasty failure mode. At the very least, open
> of new files should fail with -EIO. Preferably the fs should force a
> read-only remount on IO errors. Given that the vast majority of HFS+
> filesystems Linux is likely to be used with are on hotpluggable media,
> I think this FS should be marked EXPERIMENTAL until such integrity
> problems are addressed.

I agree. This is, indeed, very scary.


Just another data point, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - rbrito@ime.usp.br - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  reply	other threads:[~2005-03-14  3:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-13 20:36 Serious problems with HFS+ Matt Mackall
2005-03-14  3:23 ` Rogério Brito [this message]
2005-03-14 10:18 ` Roman Zippel
2005-03-15  3:11   ` Matt Mackall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050314032303.GA29808@ime.usp.br \
    --to=rbrito@ime.usp.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.