<?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://permalink.gmane.org/gmane.comp.file-systems.jfs.general">
    <title>gmane.comp.file-systems.jfs.general</title>
    <link>http://permalink.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://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3149"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3148"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3147"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3146"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3145"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3144"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3143"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3142"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3141"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3140"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3139"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3138"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3137"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3136"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3135"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3134"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3133"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3132"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3131"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3130"/>
      </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://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3149">
    <title>Re: xattr performance</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3149</link>
    <description>&lt;pre&gt;
The jfs inode is fixed at 512 bytes and space for inline xattr data is
limited to 128 bytes. Anything that won't fit here will require
allocating one or more data blocks to store the xattr.

Thanks,
Shaggy

------------------------------------------------------------------------------
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
&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-05-22T16:39:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3148">
    <title>Re: jfs resize</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3148</link>
    <description>&lt;pre&gt;
This certainly seems to be doing something wrong. I would expect it to
take roughly the same amount of time as mkfs.

Is it still running? Can you capture a stack trace or two while it's
running? /proc/&amp;lt;pid&amp;gt;/stack

Thanks,
Shaggy


------------------------------------------------------------------------------
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
&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-05-22T16:32:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3147">
    <title>[PATCH] jfs: Functions jfs_freeze() andjfs_unfreeze() always return 0</title>
    <link>http://permalink.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://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3146">
    <title>Re: xattr performance</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3146</link>
    <description>&lt;pre&gt;Hey Christian,

On Fri, May 17, 2013 at 05:02:21AM -0700, Christian Kujau wrote:

Very interesting results!  One wrinkle that you might want to consider with XFS
is the overall size of the attributes versus the size of the inode.  You can
choose inode sizes between 256 bytes and 2k in powers of two, and we always
allocate them in chunks of 64.  The 'literal' area is the space after the inode
core and before the next one... it's best described here:
http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/On-disk_Inode.html

The short version:

inode core (96 bytes) + literal area == inode size

The data and attribute forks share the literal area.  If the attributes get too
big to fit inside the literal area with the data fork they will go out of line
and be stored elsewhere in the filesystem.  The performance characteristics of
inline vs out-of-line attributes are significantly different.  That might be
what you experienced when you felt that setting/reading xattrs was taking a
long time.&lt;/pre&gt;</description>
    <dc:creator>Ben Myers</dc:creator>
    <dc:date>2013-05-17T15:44:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3145">
    <title>jfs resize</title>
    <link>http://permalink.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://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3144">
    <title>Re: [PATCH] jfs: Functions jfs_freeze() and jfs_unfreeze() always return 0</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3144</link>
    <description>&lt;pre&gt;


Reviewed-by: Gu Zheng &amp;lt;guz.fnst&amp;lt; at &amp;gt;cn.fujitsu.com&amp;gt;


"if (rc)", and the following. 

Thanks,
Gu




------------------------------------------------------------------------------
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
&lt;/pre&gt;</description>
    <dc:creator>Gu Zheng</dc:creator>
    <dc:date>2013-05-16T08:57:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3143">
    <title>Re: xattr performance</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3143</link>
    <description>&lt;pre&gt;
Ah, yes indeed. I had another issue earlier on the same filesystem and 
Christoph told me[0] that I may have run out of inode attributes. 

xfs_info reports isize=256 for this filesystem and now that I'm using 
xattr even more (I'm storing sha256 checksum plus the filename in each 
file's xattr) this looks like it might exceed the literal area after all. 


Yeah, next time I'll have to take this into consideration, but the fs was 
created long ago and I didn't plan to use xattr. Now I do but mkfs is not 
an option right now.

Thanks for the insight,
Christian.

[0] http://oss.sgi.com/archives/xfs/2012-07/msg00116.html
&lt;/pre&gt;</description>
    <dc:creator>Christian Kujau</dc:creator>
    <dc:date>2013-05-17T20:09:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3142">
    <title>xattr performance</title>
    <link>http://permalink.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://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3141">
    <title>[GIT PULL] jfs for 3.10</title>
    <link>http://permalink.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://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3140">
    <title>[PATCH V7 -next 11/33] dio: Convert direct_IO touse iov_iter</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3140</link>
    <description>&lt;pre&gt;Change the direct_IO aop to take an iov_iter argument rather than an iovec.
This will get passed down through most filesystems so that only the
__blockdev_direct_IO helper need be aware of whether user or kernel memory
is being passed to the function.

Signed-off-by: Dave Kleikamp &amp;lt;dave.kleikamp&amp;lt; at &amp;gt;oracle.com&amp;gt;
Cc: Eric Van Hensbergen &amp;lt;ericvh&amp;lt; at &amp;gt;gmail.com&amp;gt;
Cc: Ron Minnich &amp;lt;rminnich&amp;lt; at &amp;gt;sandia.gov&amp;gt;
Cc: Latchesar Ionkov &amp;lt;lucho&amp;lt; at &amp;gt;ionkov.net&amp;gt;
Cc: v9fs-developer&amp;lt; at &amp;gt;lists.sourceforge.net
Cc: Alexander Viro &amp;lt;viro&amp;lt; at &amp;gt;zeniv.linux.org.uk&amp;gt;
Cc: linux-fsdevel&amp;lt; at &amp;gt;vger.kernel.org
Cc: Chris Mason &amp;lt;chris.mason&amp;lt; at &amp;gt;fusionio.com&amp;gt;
Cc: linux-btrfs&amp;lt; at &amp;gt;vger.kernel.org
Cc: Sage Weil &amp;lt;sage&amp;lt; at &amp;gt;inktank.com&amp;gt;
Cc: ceph-devel&amp;lt; at &amp;gt;vger.kernel.org
Cc: Jan Kara &amp;lt;jack&amp;lt; at &amp;gt;suse.cz&amp;gt;
Cc: linux-ext4&amp;lt; at &amp;gt;vger.kernel.org
Cc: Andrew Morton &amp;lt;akpm&amp;lt; at &amp;gt;linux-foundation.org&amp;gt;
Cc: Andreas Dilger &amp;lt;adilger.kernel&amp;lt; at &amp;gt;dilger.ca&amp;gt;
Cc: Jaegeuk Kim &amp;lt;jaegeuk.kim&amp;lt; at &amp;gt;samsung.com&amp;gt;
Cc: linux-f2fs-devel&amp;lt; at &amp;gt;lists.sourceforge.net
Cc: OGAWA Hirofumi &amp;lt;hirofumi&amp;lt; at &amp;gt;mail.parknet.co.jp&amp;gt;
Cc: Miklos Szeredi &amp;lt;miklos&amp;lt; at &amp;gt;szeredi.hu&amp;gt;
Cc: fuse-d&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-03-08T22:52:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3139">
    <title>[PATCH V7 -next 20/33] fs: add read_iter andwrite_iter to several file systems</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3139</link>
    <description>&lt;pre&gt;These are the simple ones.

File systems that use generic_file_aio_read() and generic_file_aio_write()
can trivially support generic_file_read_iter() and generic_file_write_iter().

This patch adds those file_operations for 9p, adfs, affs, bfs, exofs, ext2,
ext3, fat, f2fs, hfs, hfsplus, hostfs, hpfs, jfs, jffs2, logfs, minix, nilfs2,
omfs, ramfs, reiserfs, romfs, sysv, and ufs.

Signed-off-by: Dave Kleikamp &amp;lt;dave.kleikamp&amp;lt; at &amp;gt;oracle.com&amp;gt;
Acked-by: Boaz Harrosh &amp;lt;bharrosh&amp;lt; at &amp;gt;panasas.com&amp;gt;
Cc: Zach Brown &amp;lt;zab&amp;lt; at &amp;gt;zabbo.net&amp;gt;
Cc: v9fs-developer&amp;lt; at &amp;gt;lists.sourceforge.net
Cc: Tigran A. Aivazian &amp;lt;tigran&amp;lt; at &amp;gt;aivazian.fsnet.co.uk&amp;gt;
Cc: Jan Kara &amp;lt;jack&amp;lt; at &amp;gt;suse.cz&amp;gt;
Cc: Andrew Morton &amp;lt;akpm&amp;lt; at &amp;gt;linux-foundation.org&amp;gt;
Cc: Andreas Dilger &amp;lt;adilger.kernel&amp;lt; at &amp;gt;dilger.ca&amp;gt;
Cc: linux-ext4&amp;lt; at &amp;gt;vger.kernel.org
Cc: OGAWA Hirofumi &amp;lt;hirofumi&amp;lt; at &amp;gt;mail.parknet.co.jp&amp;gt;
Cc: Benny Halevy &amp;lt;bhalevy&amp;lt; at &amp;gt;tonian.com&amp;gt;
Cc: osd-dev&amp;lt; at &amp;gt;open-osd.org
Cc: Jeff Dike &amp;lt;jdike&amp;lt; at &amp;gt;addtoit.com&amp;gt;
Cc: Richard Weinberger &amp;lt;richard&amp;lt; at &amp;gt;nod.at&amp;gt;
Cc: user-mode-linux-devel&amp;lt; at &amp;gt;lists.sourceforge.net
Cc: Mikulas Patocka &amp;lt;mikulas&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-03-08T22:52:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3138">
    <title>Re: [PATCH V6 18/30] fs: add read_iter and write_iter to several file systems</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3138</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/01/2013 01:51 AM, Artem Bityutskiy wrote:

Zach Brown originally came up with these (or at least he's the one who
did the majority of the initial work with this patchset) and I can't
speak for him, but I'm not sure if I could come up with a better name.
(Maybe aio_read_iter/aio_write_iter?) These operations are
differentiated from aio_read/write because they take the iov_iter
argument rather than an iovec, so "iter" does seem appropriate.


It hasn't been discussed, but nobody has said anything about the names
until now. I hesitate to change the proposed names now unless there's
some kind of consensus to do so.

If others chime in and want me to change these to aio_read_iter and
aio_write_iter or something else, I'll consider it.

Thanks,
Shaggy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRDChYAAoJEDaohF61QIxkRAkP/0HRsRwVPU/mKJx3BSlw44st
sWrbKNPhVaMpHQtJP+&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-02-01T20:40:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3137">
    <title>Re: [PATCH V6 18/30] fs: add read_iter and write_iter to several file systems</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3137</link>
    <description>&lt;pre&gt;
The new names a lot less self-documenting than the old ones - I read
them as "read iteration", because "iter" is often used for "iteration",
and this gives me no clue that they are related to AIO...

I apologize if this was already discussed, but why did you choose
"iter"?

&lt;/pre&gt;</description>
    <dc:creator>Artem Bityutskiy</dc:creator>
    <dc:date>2013-02-01T07:51:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3136">
    <title>[PATCH V6 09/30] dio: Convert direct_IO to useiov_iter</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3136</link>
    <description>&lt;pre&gt;Change the direct_IO aop to take an iov_iter argument rather than an iovec.
This will get passed down through most filesystems so that only the
__blockdev_direct_IO helper need be aware of whether user or kernel memory
is being passed to the function.

Signed-off-by: Dave Kleikamp &amp;lt;dave.kleikamp&amp;lt; at &amp;gt;oracle.com&amp;gt;
Cc: Eric Van Hensbergen &amp;lt;ericvh&amp;lt; at &amp;gt;gmail.com&amp;gt;
Cc: Ron Minnich &amp;lt;rminnich&amp;lt; at &amp;gt;sandia.gov&amp;gt;
Cc: Latchesar Ionkov &amp;lt;lucho&amp;lt; at &amp;gt;ionkov.net&amp;gt;
Cc: v9fs-developer&amp;lt; at &amp;gt;lists.sourceforge.net
Cc: Alexander Viro &amp;lt;viro&amp;lt; at &amp;gt;zeniv.linux.org.uk&amp;gt;
Cc: linux-fsdevel&amp;lt; at &amp;gt;vger.kernel.org
Cc: Chris Mason &amp;lt;chris.mason&amp;lt; at &amp;gt;fusionio.com&amp;gt;
Cc: linux-btrfs&amp;lt; at &amp;gt;vger.kernel.org
Cc: Sage Weil &amp;lt;sage&amp;lt; at &amp;gt;inktank.com&amp;gt;
Cc: ceph-devel&amp;lt; at &amp;gt;vger.kernel.org
Cc: Jan Kara &amp;lt;jack&amp;lt; at &amp;gt;suse.cz&amp;gt;
Cc: linux-ext4&amp;lt; at &amp;gt;vger.kernel.org
Cc: Andrew Morton &amp;lt;akpm&amp;lt; at &amp;gt;linux-foundation.org&amp;gt;
Cc: Andreas Dilger &amp;lt;adilger.kernel&amp;lt; at &amp;gt;dilger.ca&amp;gt;
Cc: Jaegeuk Kim &amp;lt;jaegeuk.kim&amp;lt; at &amp;gt;samsung.com&amp;gt;
Cc: linux-f2fs-devel&amp;lt; at &amp;gt;lists.sourceforge.net
Cc: OGAWA Hirofumi &amp;lt;hirofumi&amp;lt; at &amp;gt;mail.parknet.co.jp&amp;gt;
Cc: Miklos Szeredi &amp;lt;miklos&amp;lt; at &amp;gt;szeredi.hu&amp;gt;
Cc: fuse-d&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-01-29T16:23:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3135">
    <title>[PATCH V6 18/30] fs: add read_iter and write_iterto several file systems</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3135</link>
    <description>&lt;pre&gt;These are the simple ones.

File systems that use generic_file_aio_read() and generic_file_aio_write()
can trivially support generic_file_read_iter() and generic_file_write_iter().

This patch adds those file_operations for 9p, adfs, affs, bfs, exofs, ext2,
ext3, fat, f2fs, hfs, hfsplus, hostfs, hpfs, jfs, jffs2, logfs, minix, nilfs2,
omfs, ramfs, reiserfs, romfs, sysv, and ufs.

Signed-off-by: Dave Kleikamp &amp;lt;dave.kleikamp&amp;lt; at &amp;gt;oracle.com&amp;gt;
Acked-by: Boaz Harrosh &amp;lt;bharrosh&amp;lt; at &amp;gt;panasas.com&amp;gt;
Cc: Zach Brown &amp;lt;zab&amp;lt; at &amp;gt;zabbo.net&amp;gt;
Cc: v9fs-developer&amp;lt; at &amp;gt;lists.sourceforge.net
Cc: Tigran A. Aivazian &amp;lt;tigran&amp;lt; at &amp;gt;aivazian.fsnet.co.uk&amp;gt;
Cc: Jan Kara &amp;lt;jack&amp;lt; at &amp;gt;suse.cz&amp;gt;
Cc: Andrew Morton &amp;lt;akpm&amp;lt; at &amp;gt;linux-foundation.org&amp;gt;
Cc: Andreas Dilger &amp;lt;adilger.kernel&amp;lt; at &amp;gt;dilger.ca&amp;gt;
Cc: linux-ext4&amp;lt; at &amp;gt;vger.kernel.org
Cc: OGAWA Hirofumi &amp;lt;hirofumi&amp;lt; at &amp;gt;mail.parknet.co.jp&amp;gt;
Cc: Benny Halevy &amp;lt;bhalevy&amp;lt; at &amp;gt;tonian.com&amp;gt;
Cc: osd-dev&amp;lt; at &amp;gt;open-osd.org
Cc: Jeff Dike &amp;lt;jdike&amp;lt; at &amp;gt;addtoit.com&amp;gt;
Cc: Richard Weinberger &amp;lt;richard&amp;lt; at &amp;gt;nod.at&amp;gt;
Cc: user-mode-linux-devel&amp;lt; at &amp;gt;lists.sourceforge.net
Cc: Mikulas Patocka &amp;lt;mikulas&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-01-29T16:23:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3134">
    <title>Re: Negative value for inode???</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3134</link>
    <description>&lt;pre&gt;
Should I just walk back the block number I use in the 'd' command
until I get a valid inode value and presume it covers subsequent
blocks (up until the next one that yields a valid inode value)?

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 -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
&lt;/pre&gt;</description>
    <dc:creator>Craig Huff</dc:creator>
    <dc:date>2013-01-25T22:10:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3133">
    <title>Re: Negative value for inode???</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3133</link>
    <description>&lt;pre&gt;It looks like whatever data or metadata resides in that block is not an
inode extent. There really isn't a tool that examines a jfs filesystem
to determine what any particular block is being used as, but jfs_debugfs
is a really low-level tool that gives you the ability to look at certain
structures assuming that you know what resides at a certain location. In
this case it seems that you are trying to find an inode at some
arbitrary location that doesn't contain one.

On 01/25/2013 03:42 PM, Craig Huff wrote:

------------------------------------------------------------------------------
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 -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-01-25T22:07:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3132">
    <title>Re: Negative value for inode???</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3132</link>
    <description>&lt;pre&gt;Dave,

Thanks for the feedback.  Unfortunately that didn't solve my problem.

Here's specifics of my situation:

smartctl is reporting bad sectors on partition /dev/sde1, so I wanted to
find what files are affected.

I used dd to read a series of sectors bracketing the sector reported by
smartctl to /dev/null while reporting sector numbers.  I took note of the
first sector to report read errors, 1084296736.  Then I calculated the JFS
block number as ( SectorNum - PartitionStartSector ) * 512 / 4096.  The
result I got was ( 1084296736 - 63 ) * 512 / 4096 = 135537084.

Following are the results of my jfs_debugfs session for this JFS block:
# jfs_debugfs /dev/sde1
jfs_debugfs version 1.1.12, 24-Aug-2007

Aggregate Block Size: 4096

Block: 135537084     Real Address 0x81421bc000
[1] di_inostamp:        0x1c742f61      [19] di_mtime.tv_nsec:  0xc0749d49
[2] di_fileset:         1243045541              [20] di_otime.tv_sec:
0xdc1f418d
[3] di_number:          -1635135392             [21] di_otime.tv_nsec:
0x1f603111&lt;/pre&gt;</description>
    <dc:creator>Craig Huff</dc:creator>
    <dc:date>2013-01-25T21:42:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3131">
    <title>Re: Negative value for inode???</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3131</link>
    <description>&lt;pre&gt;
jfs_debugfs should be printing the inode number as unsigned, but it is
not. Just a display bug in jfs_debugfs.


This isn't an indication that anything is wrong with the inode or the
file system.


------------------------------------------------------------------------------
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 -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2013-01-24T21:53:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3130">
    <title>Negative value for inode???</title>
    <link>http://permalink.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://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3129">
    <title>Re: [PATCH V5 18/30] fs: add read_iter and write_iter to several file systems</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.jfs.general/3129</link>
    <description>&lt;pre&gt;
Thanks looks good.
ACK-by: Boaz Harrosh &amp;lt;bharrosh&amp;lt; at &amp;gt;panasas.com&amp;gt;




------------------------------------------------------------------------------
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 -- learn more at:
http://p.sf.net/sfu/learnmore_122712
&lt;/pre&gt;</description>
    <dc:creator>Boaz Harrosh</dc:creator>
    <dc:date>2013-01-10T12:40:49</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>
