<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.file-systems.jfs.general">
    <title>gmane.comp.file-systems.jfs.general</title>
    <link>http://blog.gmane.org/gmane.comp.file-systems.jfs.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3175"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3170"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3165"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3164"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3159"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3151"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3147"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3145"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3142"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3141"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3130"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3126"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3120"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3116"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3115"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3114"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3110"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3107"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3106"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3102"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3175">
    <title>jfs_fsck stucks</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3175</link>
    <description>&lt;pre&gt;Hi,
  I have a problem, which very similar in symptom to case
  reported in this post:
  &amp;lt;http://sourceforge.net/mailarchive/message.php?msg_id=29796419&amp;gt;

 I have a HDD image, on which I have 2 partitions - both JFS.

jfsutils/fsck/jfs_fsck version 1.1.15, Jun 14 2013
processing started: 6/14/2013 17:29:03
Using default parameter: -p [xchkdsk.c:3033]
The current device is:  /dev/mapper/loop1p1 [xchkdsk.c:1527]
Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 [fsckpfs.c:3233]
Primary superblock is valid. [fsckmeta.c:1551]
The type of file system for the device is JFS. [xchkdsk.c:1544]
Block size in bytes:  4096 [xchkdsk.c:1857]
Filesystem size in blocks:  526120 [xchkdsk.c:1864]
**Phase 0 - Replay Journal Log [xchkdsk.c:1871]
^C|......

I have added several traces and found that the tool is looping in this
function rXtree():

        do {
                /* read in the leftmost child page */
                if (bread(vol, pxd, (void **) &amp;amp;buf_ptr, PB_READ) != 0) {
                        fsck_send_msg(lrdo_RXT&lt;/pre&gt;</description>
    <dc:creator>Marek Skuczynski</dc:creator>
    <dc:date>2013-06-14T15:34:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3170">
    <title>[PATCH 0/2] jfs: neatening</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3170</link>
    <description>&lt;pre&gt;The second patch is speculative and maybe not necessary.

Is a 3KB reduction in object size when embedded and !CONFIG_PRINTK worth it?

Joe Perches (2):
  jfs: Update jfs_error
  jfs: Reduce object size when CONFIG_PRINTK=n

 fs/jfs/jfs_dmap.c       | 70 +++++++++++++++++++------------------------------
 fs/jfs/jfs_dtree.c      | 37 +++++++++++++-------------
 fs/jfs/jfs_extent.c     |  2 +-
 fs/jfs/jfs_imap.c       | 69 ++++++++++++++++++++----------------------------
 fs/jfs/jfs_metapage.c   |  5 ++--
 fs/jfs/jfs_superblock.h | 17 +++++++++++-
 fs/jfs/jfs_txnmgr.c     |  2 +-
 fs/jfs/jfs_xtree.c      | 62 +++++++++++++++++++++----------------------
 fs/jfs/namei.c          |  2 +-
 fs/jfs/resize.c         |  2 +-
 fs/jfs/super.c          | 24 ++++++++++-------
 fs/jfs/xattr.c          |  4 +--
 12 files changed, 142 insertions(+), 154 deletions(-)

&lt;/pre&gt;</description>
    <dc:creator>Joe Perches</dc:creator>
    <dc:date>2013-06-04T23:39:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3165">
    <title>[PATCH] jfs: Convert jfs_error to jfs_sb_err</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3165</link>
    <description>&lt;pre&gt;Use a more current logging style.

Rename function jfs_error to jfs_sb_err.
Add __printf format and argument verification.

Remove embedded function names from formats.
Add %pf, __builtin_return_address(0) to jfs_sb_err.
Add newlines to formats for kernel style consistency.
(One format already had an erroneous newline)
Coalesce formats and align arguments.

Object size reduced ~1KiB.

$ size fs/jfs/built-in.o*
   text   data    bss    dec    hexfilename
 201891  35488  63936 301315  49903fs/jfs/built-in.o.new
 202821  35488  64192 302501  49da5fs/jfs/built-in.o.old

Signed-off-by: Joe Perches &amp;lt;joe&amp;lt; at &amp;gt;perches.com&amp;gt;
---
 fs/jfs/jfs_dmap.c       | 94 ++++++++++++++++++++-----------------------------
 fs/jfs/jfs_dtree.c      | 45 ++++++++++++-----------
 fs/jfs/jfs_extent.c     |  2 +-
 fs/jfs/jfs_imap.c       | 89 +++++++++++++++++++++-------------------------
 fs/jfs/jfs_metapage.c   |  9 +++--
 fs/jfs/jfs_superblock.h |  3 +-
 fs/jfs/jfs_txnmgr.c     |  2 +-
 fs/jfs/jfs_xtree.c      | 64 ++++++++++&lt;/pre&gt;</description>
    <dc:creator>Joe Perches</dc:creator>
    <dc:date>2013-06-04T05:22:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3164">
    <title>[GIT PULL] jfs for 3.10-rc5</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3164</link>
    <description>&lt;pre&gt;The following changes since commit 514e250f67d2b2a8ab08dc9c3650af19a411c926:

  Merge tag 'gpio-fixes-v3.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio (2013-05-23 18:24:10 -0700)

are available in the git repository at:


  git://github.com/kleikamp/linux-shaggy.git tags/jfs-3.10-rc5

for you to fetch changes up to 95bbb82f60c80808e5a49d8233c2de8451901531:

  fs/jfs: Add check if journaling to disk has been disabled in lbmRead() (2013-05-24 16:03:47 -0500)

----------------------------------------------------------------
A couple jfs bug fixes for 3.10-rc5

----------------------------------------------------------------
Gu Zheng (1):
      fs/jfs: Add check if journaling to disk has been disabled in lbmRead()

Vahram Martirosyan (1):
      jfs: Several bugs in jfs_freeze() and jfs_unfreeze()

 fs/jfs/jfs_logmgr.c |  8 +++++++-
 fs/jfs/super.c      | 38 ++++++++++++++++++++++++++++++--------
 2 files changed, 37 insertions(+), 9 deletions(-)

---------------------------------------&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-06-03T15:48:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3159">
    <title>[PATCH 3.9-stable] jfs: fix a couple races</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3159</link>
    <description>&lt;pre&gt;Commit 73aaa22d5ffb2630456bac2f9a4ed9b81d0d7271 upstream

This fixes a real-world hang reported against the 3.9.3 kernel.

From: Dave Kleikamp &amp;lt;dave.kleikamp&amp;lt; at &amp;gt;oracle.com&amp;gt;

This patch fixes races uncovered by xfstests testcase 068.

One race is the result of jfs_sync() trying to write a sync point to the
journal after it has been frozen (or possibly in the process). Since
freezing sync's the journal, there is no need to write a sync point so
we simply want to return.

The second involves jfs_write_inode() being called on a deleted inode.
It calls jfs_flush_journal which is held up by the jfs_commit thread
doing the final iput on the same deleted inode, which itself is
waiting for the I_SYNC flag to be cleared. jfs_write_inode need not
do anything when i_nlink is zero, which is the easy fix.

Reported-by: Michael L. Semon &amp;lt;mlsemon35&amp;lt; at &amp;gt;gmail.com&amp;gt;
Signed-off-by: Dave Kleikamp &amp;lt;dave.kleikamp&amp;lt; at &amp;gt;oracle.com&amp;gt;
---
 fs/jfs/inode.c      | 2 +-
 fs/jfs/jfs_logmgr.c | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

di&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-05-28T14:49:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3151">
    <title>[PATCH 1/2] jfs: Several bugs in jfs_freeze() andjfs_unfreeze()</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3151</link>
    <description>&lt;pre&gt;The mentioned functions do not pay attention to the error codes returned
by the functions updateSuper(), lmLogInit() and lmLogShutdown(). It brings to
system crash later when writing to log.

The patch adds corresponding code to check and return the error codes
and to print correct error messages in case of errors.

Besides that the lmLogShutdown() function must not be called when 'nointegrity' mount option is provided.
It leads to kernel OOPS.

Found by Linux File System Verification project (linuxtesting.org).

Signed-off-by: Vahram Martirosyan &amp;lt;vahram.martirosyan&amp;lt; at &amp;gt;linuxtesting.org&amp;gt;

Reviewed-by: Gu Zheng &amp;lt;guz.fnst&amp;lt; at &amp;gt;cn.fujitsu.com&amp;gt;
---
 fs/jfs/super.c | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index 2003e83..a3d424d 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -611,11 +611,20 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int jfs_freeze(struct super_block *sb)
 {
 struct jfs_sb_info *sbi = JFS_SBI(sb);
 struct jfs_log *log = sbi-&amp;gt;log;
+int rc = 0;
&lt;/pre&gt;</description>
    <dc:creator>Vahram Martirosyan</dc:creator>
    <dc:date>2013-05-24T08:57:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3147">
    <title>[PATCH] jfs: Functions jfs_freeze() andjfs_unfreeze() always return 0</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3147</link>
    <description>&lt;pre&gt;The mentioned functions do not pay attention to the error codes returned
by the functions updateSuper(), lmLogInit() and lmLogShutdown(). It brings to
system crash later when writing to log.

The patch adds corresponding code to check and return the error codes
and to print correct error messages in case of errors.

Found by Linux File System Verification project (linuxtesting.org).

Signed-off-by: Vahram Martirosyan &amp;lt;vahram.martirosyan&amp;lt; at &amp;gt;linuxtesting.org&amp;gt;
---
 fs/jfs/super.c | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index 2003e83..a3d424d 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -611,11 +611,20 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int jfs_freeze(struct super_block *sb)
 {
 struct jfs_sb_info *sbi = JFS_SBI(sb);
 struct jfs_log *log = sbi-&amp;gt;log;
+int rc = 0;
 
 if (!(sb-&amp;gt;s_flags &amp;amp; MS_RDONLY)) {
 txQuiesce(sb);
-lmLogShutdown(log);
-updateSuper(sb, FM_CLEAN);
+rc = lmLogShutdown(log);
+if (rc != 0) {
+jfs_err("lmLogShutdown&lt;/pre&gt;</description>
    <dc:creator>Vahram Martirosyan</dc:creator>
    <dc:date>2013-05-16T05:14:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3145">
    <title>jfs resize</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3145</link>
    <description>&lt;pre&gt;Hello everyone,

I have a large JFS partition (100 TB - yes terabytes) hosted on an LVM partition. I proceeded to grow the LVM partition to 200TB. Then I started a resize in JFS. The resize has now been running 24 hours and it is still not complete.

How long (hours, days, etc) would you expect a function like this to take? The mkfs.jfs completed relatively quick - a few minutes. Thus I expected this to take a similar amount of time.

Thanks
Jason
------------------------------------------------------------------------------
Try New Relic Now &amp;amp; We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, &amp;amp; servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
Jfs-discussion mailing list
Jfs-discussion&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/l&lt;/pre&gt;</description>
    <dc:creator>Kiebzak, Jason M.</dc:creator>
    <dc:date>2013-05-21T13:08:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3142">
    <title>xattr performance</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3142</link>
    <description>&lt;pre&gt;Hi,

a while ago I was setting &amp;amp; reading extended attributes to ~25000 files 
in a directory structure on an XFS filesystem. The files were usually a 
few MB in size, but some where up to 2GB in size.

Anyway, I *felt* that setting or reading these xattrs was going very
slowly. While the storage may be not the fastest, stat()'ing these
files was fine, but getfattr/setfattr took very long.

I got curious and while it turned out that the slowness was related to the 
wrapper script I used to read/set those values, I created a little test 
suite to 1) create a few thousand files and 2) do xattr operations on 
them and see if xattr performance was filesystem specific:

   http://nerdbynature.de/bits/xattr/

Not very sophisticated, true. But it was interesting to see that 
ext3/ext4/xfs behaved kinda well for all these tests; btrfs/jfs/reiserfs
sometimes took way longer than the others.

Christian.
&lt;/pre&gt;</description>
    <dc:creator>Christian Kujau</dc:creator>
    <dc:date>2013-05-17T12:02:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3141">
    <title>[GIT PULL] jfs for 3.10</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3141</link>
    <description>&lt;pre&gt;The following changes since commit 5f243b9b46a22e5790dbbc36f574c2417af49a41:

  Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 (2013-01-04 10:41:54 -0800)

are available in the git repository at:


  git://github.com/kleikamp/linux-shaggy.git tags/jfs-3.10

for you to fetch changes up to 73aaa22d5ffb2630456bac2f9a4ed9b81d0d7271:

  jfs: fix a couple races (2013-05-01 11:16:59 -0500)

----------------------------------------------------------------
Dave Kleikamp (1):
      jfs: fix a couple races

Nickolai Zeldovich (1):
      jfs: avoid undefined behavior from left-shifting by 32 bits

 fs/jfs/inode.c      | 2 +-
 fs/jfs/jfs_imap.c   | 2 +-
 fs/jfs/jfs_logmgr.c | 3 ++-
 3 files changed, 4 insertions(+), 3 deletions(-)

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, &lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-05-03T15:37:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3130">
    <title>Negative value for inode???</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3130</link>
    <description>&lt;pre&gt;Short form is that I used jfs_debugfs to query for inode info for block
135537084 using "d 135537084 0 i" and di_number was returned as a negative
value.  I got the same value for iagnum using the command "d 135537084 0
I".  What gives?  Is this an instance of a note I found on the web about a
bug that would put a JFS error number in the inode and as a result corrupt
file data on the partition (for one file? for the directory containing the
affected file? for the whole partition?)?

Do I need to offload the files from the partition before taking any
corrective action?  Should fsck fix the problem?  Will I need to reformat
the partition to resolve this?

Any advice appreciated.

Craig.
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only &lt;/pre&gt;</description>
    <dc:creator>Craig Huff</dc:creator>
    <dc:date>2013-01-24T20:17:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3126">
    <title>[PATCH 12/21] jfs: drop vmtruncate</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3126</link>
    <description>&lt;pre&gt;Removed vmtruncate

Signed-off-by: Marco Stornelli &amp;lt;marco.stornelli&amp;lt; at &amp;gt;gmail.com&amp;gt;
---
 fs/jfs/file.c  |    6 ++++--
 fs/jfs/inode.c |   20 ++++++++++++++------
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/fs/jfs/file.c b/fs/jfs/file.c
index 9d3afd1..dd7442c 100644
--- a/fs/jfs/file.c
+++ b/fs/jfs/file.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -119,9 +119,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int jfs_setattr(struct dentry *dentry, struct iattr *iattr)
     iattr-&amp;gt;ia_size != i_size_read(inode)) {
 inode_dio_wait(inode);
 
-rc = vmtruncate(inode, iattr-&amp;gt;ia_size);
+rc = inode_newsize_ok(inode, iattr-&amp;gt;ia_size);
 if (rc)
 return rc;
+
+truncate_setsize(inode, iattr-&amp;gt;ia_size);
+jfs_truncate(inode);
 }
 
 setattr_copy(inode, iattr);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -133,7 +136,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int jfs_setattr(struct dentry *dentry, struct iattr *iattr)
 }
 
 const struct inode_operations jfs_file_inode_operations = {
-.truncate= jfs_truncate,
 .setxattr= jfs_setxattr,
 .getxattr= jfs_getxattr,
 .listxattr= jfs_listxattr,
diff --git a/fs/jfs/inode.c b/fs/jfs/inode.c
index 4692bf3..b7&lt;/pre&gt;</description>
    <dc:creator>Marco Stornelli</dc:creator>
    <dc:date>2012-12-15T10:54:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3120">
    <title>[PATCH 12/21] jfs: drop vmtruncate</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3120</link>
    <description>&lt;pre&gt;Removed vmtruncate

Signed-off-by: Marco Stornelli &amp;lt;marco.stornelli&amp;lt; at &amp;gt;gmail.com&amp;gt;
---
 fs/jfs/file.c  |    6 ++++--
 fs/jfs/inode.c |   20 ++++++++++++++------
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/fs/jfs/file.c b/fs/jfs/file.c
index 9d3afd1..dd7442c 100644
--- a/fs/jfs/file.c
+++ b/fs/jfs/file.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -119,9 +119,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int jfs_setattr(struct dentry *dentry, struct iattr *iattr)
     iattr-&amp;gt;ia_size != i_size_read(inode)) {
 inode_dio_wait(inode);
 
-rc = vmtruncate(inode, iattr-&amp;gt;ia_size);
+rc = inode_newsize_ok(inode, iattr-&amp;gt;ia_size);
 if (rc)
 return rc;
+
+truncate_setsize(inode, iattr-&amp;gt;ia_size);
+jfs_truncate(inode);
 }
 
 setattr_copy(inode, iattr);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -133,7 +136,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int jfs_setattr(struct dentry *dentry, struct iattr *iattr)
 }
 
 const struct inode_operations jfs_file_inode_operations = {
-.truncate= jfs_truncate,
 .setxattr= jfs_setxattr,
 .getxattr= jfs_getxattr,
 .listxattr= jfs_listxattr,
diff --git a/fs/jfs/inode.c b/fs/jfs/inode.c
index 4692bf3..b7&lt;/pre&gt;</description>
    <dc:creator>Marco Stornelli</dc:creator>
    <dc:date>2012-11-03T09:28:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3116">
    <title>[GIT PULL] jfs bug fix for 3.7</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3116</link>
    <description>&lt;pre&gt;The following changes since commit 8d2b6b3ae280dcf6f6c7a95623670a57cdf562ed:

  Merge tag 'sh-for-linus' of git://github.com/pmundt/linux-sh (2012-10-16 19:24:00 -0700)

are available in the git repository at:


  git://github.com/kleikamp/linux-shaggy.git tags/jfs-3.7-2

for you to fetch changes up to 4e7a4b01222343481d8ff084dbef9b80f7089a19:

  jfs: Fix FITRIM argument handling (2012-10-17 09:18:38 -0500)

----------------------------------------------------------------
Bug fix: Fix FITRIM argument handling

----------------------------------------------------------------
Lukas Czerner (1):
      jfs: Fix FITRIM argument handling

 fs/jfs/jfs_discard.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2012-10-22T22:24:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3115">
    <title>[PATCH 12/21] jfs: drop vmtruncate</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3115</link>
    <description>&lt;pre&gt;Removed vmtruncate

Signed-off-by: Marco Stornelli &amp;lt;marco.stornelli&amp;lt; at &amp;gt;gmail.com&amp;gt;
---
 fs/jfs/file.c  |    6 ++++--
 fs/jfs/inode.c |   20 ++++++++++++++------
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/fs/jfs/file.c b/fs/jfs/file.c
index 9d3afd1..dd7442c 100644
--- a/fs/jfs/file.c
+++ b/fs/jfs/file.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -119,9 +119,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int jfs_setattr(struct dentry *dentry, struct iattr *iattr)
     iattr-&amp;gt;ia_size != i_size_read(inode)) {
 inode_dio_wait(inode);
 
-rc = vmtruncate(inode, iattr-&amp;gt;ia_size);
+rc = inode_newsize_ok(inode, iattr-&amp;gt;ia_size);
 if (rc)
 return rc;
+
+truncate_setsize(inode, iattr-&amp;gt;ia_size);
+jfs_truncate(inode);
 }
 
 setattr_copy(inode, iattr);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -133,7 +136,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int jfs_setattr(struct dentry *dentry, struct iattr *iattr)
 }
 
 const struct inode_operations jfs_file_inode_operations = {
-.truncate= jfs_truncate,
 .setxattr= jfs_setxattr,
 .getxattr= jfs_getxattr,
 .listxattr= jfs_listxattr,
diff --git a/fs/jfs/inode.c b/fs/jfs/inode.c
index 4692bf3..b7&lt;/pre&gt;</description>
    <dc:creator>Marco Stornelli</dc:creator>
    <dc:date>2012-10-20T12:22:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3114">
    <title>[PATCH 00/21 v3] drop vmtruncate</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3114</link>
    <description>&lt;pre&gt;Hi all,

I sent the third version of the patch series. After a couple of comments 
by Al and Christoph, now the patches are no more 1:1 replace of 
vmtruncate. A lot of inode_newsize_ok() and truncate_setsize() are now 
gone. For each fs, where needed, I wrote a new fs_write_failed() (as 
suggested by Al watching the ext2 code). The modifications are a bit 
deeper and they are *not* tested. I ask for comments to each fs 
maintainers. I hope the series can be pushed for 3.8.

Changes:
v3: reworked after Al and Christoph comments
v2: add documentation cleaning
v1: first draft

Marco Stornelli (21):
   ufs: drop vmtruncate
   sysv: drop vmtruncate
   reiserfs: drop vmtruncate
   procfs: drop vmtruncate
   omfs: drop vmtruncate
   ocfs2: drop vmtruncate
   adfs: drop vmtruncate
   affs: drop vmtruncate
   bfs: drop vmtruncate
   hfs: drop vmtruncate
   hpfs: drop vmtruncate
   jfs: drop vmtruncate
   hfsplus: drop vmtruncate
   logfs: drop vmtruncate
   minix: drop vmtruncate
   ncpfs: drop vmtruncate
   nilfs2:&lt;/pre&gt;</description>
    <dc:creator>Marco Stornelli</dc:creator>
    <dc:date>2012-10-20T12:14:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3110">
    <title>[PATCH] jfs: Fix FITRIM argument handling</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3110</link>
    <description>&lt;pre&gt;Currently when 'range-&amp;gt;start' is beyond the end of file system
nothing is done and that fact is ignored, where in fact we should return
EINVAL. The same problem is when 'range.len' is smaller than file system
block.

Fix this by adding check for such conditions and return EINVAL
appropriately.

Signed-off-by: Lukas Czerner &amp;lt;lczerner&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 fs/jfs/jfs_discard.c |   16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/fs/jfs/jfs_discard.c b/fs/jfs/jfs_discard.c
index 9947563..dfcd503 100644
--- a/fs/jfs/jfs_discard.c
+++ b/fs/jfs/jfs_discard.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -83,7 +83,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int jfs_ioc_trim(struct inode *ip, struct fstrim_range *range)
 struct bmap *bmp = JFS_SBI(ip-&amp;gt;i_sb)-&amp;gt;bmap;
 struct super_block *sb = ipbmap-&amp;gt;i_sb;
 int agno, agno_end;
-s64 start, end, minlen;
+u64 start, end, minlen;
 u64 trimmed = 0;
 
 /**
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -93,15 +93,19 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int jfs_ioc_trim(struct inode *ip, struct fstrim_range *range)
  * minlen:minimum extent length in Bytes
  */
 start = range-&amp;gt;start &amp;gt;&amp;gt; sb-&amp;gt;s&lt;/pre&gt;</description>
    <dc:creator>Lukas Czerner</dc:creator>
    <dc:date>2012-10-16T09:38:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3107">
    <title>finding inodes via block</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3107</link>
    <description>&lt;pre&gt;I have a jfs partition on a linux 2.6.32 install on which 3 sectors recently
became unreadable.  I was able to write zeros to those sectors using dd and
the disk appears to think they're fine and readable again; at least no
sectors are marked reallocated or currently pending by the disk.

  dd of=/dev/sdc if=/dev/zero seek=640 count=1 bs=4096
  dd of=/dev/sdc if=/dev/zero seek=935 count=1 bs=4096
  dd of=/dev/sdc if=/dev/zero seek=1283 count=1 bs=4096

I would like to find out which files on the disk were in those blocks and
thus are now damaged.  Since I have the logical block numbers I assume I 
can get inode numbers from them somehow.

Tried using the 'd' command in jfs_debugfs but am not able to get anything 
that remotely looks correct.  Probably I'm not using a correct offset value, but
I have no idea what I should give it.  Is there a better method?

  Disk /dev/sdc: 3907029168s
  Sector size (logical/physical): 512B/512B
  Partition Table: gpt
  
  Number  Start  End          Size         File system&lt;/pre&gt;</description>
    <dc:creator>Robert Henney</dc:creator>
    <dc:date>2012-10-12T15:33:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3106">
    <title>[PATCH 12/22] jfs: drop vmtruncate</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3106</link>
    <description>&lt;pre&gt;Removed vmtruncate.

Signed-off-by: Marco Stornelli &amp;lt;marco.stornelli&amp;lt; at &amp;gt;gmail.com&amp;gt;
---
 fs/jfs/file.c  |    6 ++++--
 fs/jfs/inode.c |   13 +++++++++----
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/fs/jfs/file.c b/fs/jfs/file.c
index 9d3afd1..dd7442c 100644
--- a/fs/jfs/file.c
+++ b/fs/jfs/file.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -119,9 +119,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int jfs_setattr(struct dentry *dentry, struct iattr *iattr)
     iattr-&amp;gt;ia_size != i_size_read(inode)) {
 inode_dio_wait(inode);
 
-rc = vmtruncate(inode, iattr-&amp;gt;ia_size);
+rc = inode_newsize_ok(inode, iattr-&amp;gt;ia_size);
 if (rc)
 return rc;
+
+truncate_setsize(inode, iattr-&amp;gt;ia_size);
+jfs_truncate(inode);
 }
 
 setattr_copy(inode, iattr);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -133,7 +136,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int jfs_setattr(struct dentry *dentry, struct iattr *iattr)
 }
 
 const struct inode_operations jfs_file_inode_operations = {
-.truncate= jfs_truncate,
 .setxattr= jfs_setxattr,
 .getxattr= jfs_getxattr,
 .listxattr= jfs_listxattr,
diff --git a/fs/jfs/inode.c b/fs/jfs/inode.c
index 4692bf3..895be2e &lt;/pre&gt;</description>
    <dc:creator>Marco Stornelli</dc:creator>
    <dc:date>2012-10-06T08:29:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3102">
    <title>[GIT PULL] JFS updates for 3.7</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3102</link>
    <description>&lt;pre&gt;Linus,

It's been a while, but I've got some JFS updates for you.

The following changes since commit fbcbe2b3c92ee1c930dcfcf8bb764074c100fd63:

  Merge tag 'sound-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2012-09-13 19:51:41 +0800)

are available in the git repository at:

  git://github.com/kleikamp/linux-shaggy.git tags/jfs-3.7

for you to fetch changes up to 84f4141ee3ea11035f741d4298cb6bbad1850fcf:

  jfs: Fix do_div precision in commit b40c2e66 (2012-09-18 11:27:22 -0500)

----------------------------------------------------------------
JFS TRIM support and some minor fixes

----------------------------------------------------------------
Dave Kleikamp (2):
      jfs: Remove obsolete email address
      jfs: Fix do_div precision in commit b40c2e66

Tino Reichardt (1):
      fs/jfs: TRIM support for JFS Filesystem

Wei Yongjun (1):
      JFS: use list_move instead of list_del/list_add

 Documentation/filesystems/jfs.txt |  19 ++++--
 fs/jfs/Makefile                   |   2 +-
 f&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2012-10-03T14:15:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3095">
    <title>[PATCH] fs/jfs: Patch with various fixes for theJFS code.</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.jfs.general/3095</link>
    <description>&lt;pre&gt;Hello,

here is a list of the changed files and the reason of it.


fs/jfs/jfs_dmap.c:
- potential NULL dereference of 'mp' in dbUpdatePMap()

fs/jfs/jfs_dtree.c:
- potential NULL dereference of 'parent' dtExtendPage()
- potential NULL dereference of 'lh' in dtInsertEntry()
- potential NULL dereference of 'ih' in dtInsertEntry()
- potential NULL dereference of 'dlh' in dtMoveEntry()
- potential NULL dereference of 'dih' in dtMoveEntry()

fs/jfs/jfs_imap.c:
- potential NULL dereference of 'aiagp' in diNewExt()
- potential NULL dereference of 'biagp' in diNewExt()
- potential NULL dereference of 'ciagp' in diNewExt()

fs/jfs/jfs_incore.h:
- added a new struct slink within the union u of the struct jfs_inode_info
- this struct slink defines _inline data to be 256 byte, which was implicitly
  used already this way for symlinks
- the following files are affected:
  - jfs_imap.c in diWrite(), line 786 via 'jfs_ip-&amp;gt;u.link._inline'
  - inode.c in jfs_iget(), line 69 via 'JFS_IP(inode)-&amp;gt;u.link._inline'
  - namei.c in&lt;/pre&gt;</description>
    <dc:creator>Tino Reichardt</dc:creator>
    <dc:date>2012-09-21T13:07:46</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.file-systems.jfs.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.file-systems.jfs.general</link>
  </textinput>
</rdf:RDF>
