Christian Kujau | 17 May 08:44 2016

jfs: possible irq lock inversion dependency detected

This just happend on a PowerPC (32 bit) box running Debian/stable and a 
vanilla 4.6.0-rc7 kernel:

[ INFO: possible irq lock inversion dependency detected ]
4.6.0-rc7 #2 Not tainted
kswapd0/272 just changed the state of lock:
 (&jfs_ip->rdwrlock#2){++++-.}, at: [<c01f0840>] jfs_get_block+0x50/0x370
but this lock took another, RECLAIM_FS-unsafe lock in the past:

Full dmesg & .config:

The system is still up & running and I didn't notice any ill effects so 
far. The box has its root disk formatted with with JFS for a long time
now and this has never happened and I suspect an ongoing compile job must
have triggered the lockdep warning, as the box isn't normally doing much 

I found a similar report[0] from 2009 and also one in the kernel 
bugzilla[1], but both are really old.



BOFH excuse #148:
(Continue reading)

Dave Kleikamp | 16 May 23:08 2016

[GIT PULL] jfs changes for 4.7

The following changes since commit 1993b176a8224e371e0732ffada7ab9eb3b0912b:

  Merge git:// (2016-03-28 15:17:02 -0500)

are available in the git repository at:

  git:// tags/jfs-4.7

for you to fetch changes up to 6ed71e9819ac3412fc6a3495f5ce141df274c916:

  jfs: Coalesce some formats (2016-03-30 10:48:28 -0500)

Some jfs logging cleanups from Joe Perches

Joe Perches (3):
      jfs: Remove terminating newlines from jfs_info, jfs_warn, jfs_err uses
      jfs: Remove unnecessary line continuations and terminating newlines
      jfs: Coalesce some formats

 fs/jfs/inode.c       |  4 ++--
 fs/jfs/jfs_discard.c |  6 ++----
 fs/jfs/jfs_dtree.c   | 10 ++++------
 fs/jfs/jfs_imap.c    |  3 +--
 fs/jfs/jfs_inode.c   |  2 +-
 fs/jfs/jfs_logmgr.c  | 14 ++++++--------
 fs/jfs/jfs_txnmgr.c  | 21 +++++++++------------
 fs/jfs/namei.c       |  4 ++--
 fs/jfs/super.c       |  4 ++--
(Continue reading)

Andreas Gruenbacher | 22 Apr 14:43 2016

[PATCH 1/2] jfs: Clean up xattr name mapping

Instead of stripping "os2." prefixes in __jfs_setxattr, make callers
strip them, as __jfs_getxattr already does.  With that change, use the
same name mapping function in jfs_{get,set,remove}xattr.

Signed-off-by: Andreas Gruenbacher <agruenba <at>>
 fs/jfs/xattr.c | 80 ++++++++++++++++++----------------------------------------
 1 file changed, 25 insertions(+), 55 deletions(-)

diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c
index 5becc6a..9cdf7dc 100644
--- a/fs/jfs/xattr.c
+++ b/fs/jfs/xattr.c
 <at>  <at>  -86,6 +86,14  <at>  <at>  struct ea_buffer {
 #define EA_MALLOC	0x0008

+ * Mapping of on-disk attribute names: for on-disk attribute names with an
+ * unknown prefix (not "system.", "user.", "security.", or "trusted."), the
+ * prefix "os2." is prepended.  On the way back to disk, "os2." prefixes are
+ * stripped and we make sure that the remaining name does not start with one
+ * of the know prefixes.
+ */
 static int is_known_namespace(const char *name)
 <at>  <at>  -97,29 +105,19  <at>  <at>  static int is_known_namespace(const char *name)
 	return true;
(Continue reading)

Hanno Böck | 15 Apr 15:08 2016

segfaults in jfs_fsck via fuzzing


I did some fuzzing on jfsutils. It uncovered two segfaults that look
like null pointer accesses.

The first one (in function (ujfs_rw_diskblocks) seems to be fixed in CVS
already, but there hasn't been a release for years. The second one also
affects the current CVS code (function v_fsck_send_msg).

I have attached sample files (just run jfs_fsck on them to see the
crash) and a stack trace from address sanitizer.

Also one note: The jfs webpage contains a broken link the sourceforge
bugtracker for reporting bugs in the menu.
The link doesn't work because it tries to load it in a frame and
sourceforge blocks that via X-Frame-Options.
But even if one manually calls that page it has bug creation disabled.

This all looks like jfs may be a dead project, but reporting this


Hanno Böck

mail/jabber: hanno <at>
Attachment (jfs_fsck-crashes.tar.xz): application/x-xz, 15 KiB
(Continue reading)

Joe Perches | 30 Mar 14:23 2016

[PATCH 0/3] jfs: logging neatening

This patchset fixes the uses of jfs_info, jfs_warn and jfs_err that
have terminating newlines and a couple other trivialities to make
the logging a bit more consistent.

There is a difference in use between jfs_error and the other
jfs_info, jfs_warn, and jfs_err logging macros.  jfs_error is more
like the rest of the kernel and requires a newline as the last
character of the format.

The jfs_info, jfs_warn, and jfs_err macros add the terminating
newline to the format so the uses do not require them.

It is a habituated style for many people to add the terminating
newline for many people and this difference in use between the
various macro styles causes trivial defects in logging output.

It might be better if the jfs_info, jfs_warn, and jfs_err macros
were changed to require a newline termination and the uses changed
to include the newline, but that's a larger change.

Joe Perches (3):
  jfs: Remove terminating newlines from jfs_info, jfs_warn, jfs_err uses
  jfs: Remove unnecessary line continuations and terminating newlines
  jfs: Coalesce some formats

 fs/jfs/inode.c       |  4 ++--
 fs/jfs/jfs_discard.c |  6 ++----
 fs/jfs/jfs_dtree.c   | 10 ++++------
 fs/jfs/jfs_imap.c    |  3 +--
 fs/jfs/jfs_inode.c   |  2 +-
(Continue reading)

Dave Kleikamp | 8 Mar 00:32 2016

Re: Problem: overflow in fs/jfs/jfs_imap.c

On 03/07/2016 03:40 PM, sambesselink <at> wrote:
> Hi Dave,
> Moving from kernel 4.1.7 to 4.4.2 for me resulted in an overflow in
> function diMount in fs/jfs/jfs_imap.c
> When mounting a JFS partition, PAX notes the following:
> 'PAX: size overflow detected in function diMount fs/jfs/jfs_imap.c:143
> cicus.289_68 max, count: 23, decl: inofree; num: 0; context: iagctl;'
> I got this on a Gentoo with gcc version 4.8.5 (Gentoo Hardened 4.8.5
> p1.3, pie-0.6.2) (see also [1]). Someone else seems to also have bumped
> into this, as reported here [2].
> If there is anything I can do to help, please let me know.

[2] indicates that the problem is an incompatibility between the signed
structure members and their __le32 on-disk counterparts, since __le32 is
defined as unsigned. The simplest solution would be to make all of them
unsigned. I've responded to [2] to ask advice, since I'm not familiar
with PAX.

> Kind regards,
> Sam
> [1]
> [2]

(Continue reading)

alanb | 9 Feb 01:43 2016

File transfer speed slows 10x and more after reaching 1TB in size

I've been using JFS on Linux Debian distributions since Lenny, currently 
using Jessie, and it's always worked well for me, however I've never 
worked with files over 1TB in size until a few days ago.

Using gddrescue I created a 2TB disk image file from a good 2TB drive 
onto a good 4TB drive, the performance at the start was as expected, 
however once it reached about 1TB the performance dropped from about 
100-120Mb/s down to 3-5Mb/s.

When using gddrescue to copy the image file to another 4TB disk, it 
again dropped to a crawl after reaching the mid-way point at 1TB. Using 
gddrescue I could reverse direction of the transfer, and that would 
speed things up to about 20-10MB/s but it would again slow to a crawl as 
it approached the mid-way point at 1TB.

I also tried using rsync to copy the image file, but got the same 
results, so the problem was not due to gddrescure. I tried two separate 
4TB disks and got the same results. Both disks (4TB WD "green") are 
brand new and I've never had problems with these disks before, and SMART 
status is all OK. I can copy a 500GB disk image, made using the exact 
same process as the 2TB image, between disks no problem, so it appears 
to be related to the size exceeding 1TB.

When extracting the file system from the 2TB disk image, the same 
behavior is seen, at about the 1TB point, the file extraction process 
quickly slows down 10x and reaches a low point of about 3Mb/s, it begins 
to gradually speed up after the midway point but never reaches full 
speed again (I get only 10-20Mb/s).

After file system extraction completes (many hours later), the complete 
(Continue reading)

Jernej Simončič | 22 Aug 21:33 2015

jfs_fsck segfaults

My home server crashed yesterday overnight, and when I rebooted it in
the morning, fsck segfaulted when checking my /var partition. My
system is Gentoo Linux ~amd64, jfsutils version 1.1.15, kernel 4.0.7.

Since I wanted the machine back and running as soon as possible, I
mounted /var read-only, copied off whatever I could, and formatted the
partition again, but I saved an image of the partition before doing
that. Here's the jfs_fsck output:



< Jernej Simončič ><><><><><><><><><><><>< >

           Because 10 billion years' time is so fragile, so ephemeral...
it arouses such a bittersweet, almost heartbreaking fondness.

Jfs-discussion mailing list
Jfs-discussion <at>
Daniel Cegiełka | 3 Aug 11:42 2015

jfsutils: development status and license


It seems that jfsutils is not actively developed. The last version was
published in 2011. Is this package will be further developed?

I also have two questions relating to license.

I want to build support for JFS in lua language. This will allow to
interactively work at a low level with JFS (eg. better debugging and
testing). The problem is that lua is released under the MIT license,
and jfsutils under the GPL. Is it possible to write such tool without
breaking the GPL. I'm afraid that GPL will in this case too

I would also build basic support for JFS (mkfs.jsf and fsck.jfs) in
the toybox ( I am afraid that such
support for JFS can be very difficult to implement, because toybox is
published under the BSD license. Is it necessary to rewrite the whole
JFS functionality from scratch, so as not to violate the GPL?

Is it possible to publish jfsutils on a more liberal license (MIT,
BSD)? Currently, JFS can not compete with XFS, and without good
support for this filesystem JFS will become increasingly marginalized.

Best regards,

Dave Kleikamp | 16 Jul 15:46 2015

[GIT PULL] jfs changes for 4.2-rc3

The following changes since commit c65b99f046843d2455aa231747b5a07a999a9f3d:

  Linux 4.1-rc6 (2015-05-31 19:01:07 -0700)

are available in the git repository at:

  git:// tags/jfs-4.2

for you to fetch changes up to 26456955719b79cc4a011b18221aa68f599f6b6c:

  jfs: clean up jfs_rename and fix out of order unlock (2015-07-15 14:11:30 -0500)

A couple trivial fixes and an error path fix

Colin Ian King (1):
      jfs: fix indentation on if statement

Dave Kleikamp (1):
      jfs: clean up jfs_rename and fix out of order unlock

Nan Jia (1):
      jfs: removed a prohibited space after opening parenthesis

 fs/jfs/file.c  |  2 +-
 fs/jfs/inode.c |  4 ++--
 fs/jfs/namei.c | 27 +++++++++++++--------------
 3 files changed, 16 insertions(+), 17 deletions(-)

(Continue reading)

Jan Kara | 15 Jul 14:42 2015

[PATCH 0/6] quota: Propagate errors when creating quota entry


  this patch set makes quota code report errors when quota entry creation fails (upto
now such errors were silently ignored). Filesystems can then properly handle the errors
and report them to userspace. Patch set also includes patches to all filesystems to
properly handle the errors. Review by respective fs maintainers is welcome.

If noone objects, I will queue these patches in my tree for the next merge window.


Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.