mirror of https://lore.kernel.org/lkml/
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®