archive mirror
 help / color / mirror / Atom feed
From: Vyacheslav Dubeyko <>
Cc: Michael Fox <>,
Subject: Re: hfsplus volume suddenly inaccessable after 'hfs: recoff %d too large'
Date: Sun, 7 Apr 2013 18:14:51 +0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Apr 7, 2013, at 5:41 PM, Hin-Tak Leung wrote:

> --- On Sun, 7/4/13, Vyacheslav Dubeyko <> wrote:
>> Hi Hin-Tak,
>> On Apr 5, 2013, at 12:57 AM, Hin-Tak Leung wrote:
>>> Hi Michael,
>>> Argh, that looks suspiciously like the recurring
>> problem I have been trying to pin down for the much of the
>> last year. My current thinking is that one of the patches
>> posted a couple of weeks ago might help.
>> As I remember, you can easily reproduce the issue that you
>> are investigating. Does the issue reproducible with enabled
>> debug output? Can you reproduce the issue with fully enabled
>> debug output (I mean to enable all debug flags)? If you can
>> reproduce the issue with enabled debug output then could you
>> share this debug output with me?
> That's correct - I can trigger the error condition with debug enabled quite reasonably "reliably". I remembered having done that once, I think with catalog and extent debugging on. The problem was that it generated too much information; since I needed to run "du" on a large directory (~million files) to trigger the condition, the catalog debugging info is a few lines per file, and "du" gets at every of the ~million files, so we are talking about dumping a few hundred MBs into /var/log/messages :-(.

Yes, I understand that the debug output can be a huge in size. But we need to to take into consideration only the output near the point of issue's occurrence. So, I think that it is possible to reduce debug output into smaller size. I understand that such filtering can be not so easy task. But we need to localize the issue's reason anyway by means of debug output analyzing.

With the best regards,
Vyacheslav Dubeyko. 

> Hence another reason to switching to dynamic debugging also - so that one can switch on/off per debugging lines. Even that is not ideal.
>> Thanks,
>> Vyacheslav Dubeyko.
>>> That patch addresses out-of-memory conditions in
>> caching of metadata, in a nutshell. I think if (1) the
>> system is under memory stress, (2) one is doing something
>> which transverse the file system very quickly, (3) on a
>> mult-CPU/core system, it is possible to run some mutexed
>> non-re-entrant code in the hfsplus simultaneously without a
>> mutex lock, and therefore get it a bit confused. This idea
>> at least explains why (1) adding an inner mutex lock can
>> delay the problem although supposedly the outer mutex should
>> have prevented more than one copy of the non-re-entrant code
>> from being run and the inner mutex lock should have no
>> effect at all, (2) the on-disk data is always fsck'ed okay -
>> it is just the driver itself getting confused.
>>> So I have a few questions for you:
>>> 1. You are on a quad-core system, correct? This is
>> according to your /proc/cpuinfo below.
>>> 2. You are certainly doing fast file system transversal
>> (updatedb), but are you actually doing it *on top of the
>> hfsplus* file system? I am asking this because updatedb is
>> usually configured not the index removable media under /mnt
>> or /media . But you mentioned you have the hfsplus system
>> mounted under /home - please confirm that and include some
>> more details if you can.
>>> 3. How full and populous is that hfs+ file system? i.e.
>> the output of both "df" and "df -i" while it is mounted. Is
>> this your Mac OS X system (root / ) disk?
>>> 4. Is your system under memory stress at the moment the
>> problem happens - e.g. you have a web browser with a few
>> hundred tabs open?
>>> Hin-Tak
>>> --- On Thu, 4/4/13, Vyacheslav Dubeyko <>
>> wrote:
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to
> More majordomo info at

  reply	other threads:[~2013-04-07 14:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2013-04-04 17:23 ` Fwd: Michael Fox
2013-04-04 17:43   ` Michael Fox
2013-04-04 18:00     ` hfsplus volume suddenly inaccessable after 'hfs: recoff %d too large' Vyacheslav Dubeyko
2013-04-04 20:57       ` Hin-Tak Leung
2013-04-05  5:20         ` Michael Fox
2013-04-07 13:54           ` Hin-Tak Leung
2013-04-07 12:12         ` Vyacheslav Dubeyko
2013-04-07 13:41           ` Hin-Tak Leung
2013-04-07 14:14             ` Vyacheslav Dubeyko [this message]
2013-04-05  5:01       ` Michael Fox
2013-04-07 12:05         ` Vyacheslav Dubeyko

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:

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

  git send-email \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).