<?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.ext4">
    <title>gmane.comp.file-systems.ext4</title>
    <link>http://blog.gmane.org/gmane.comp.file-systems.ext4</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.ext4/32494"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32493"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32490"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32488"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32487"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32486"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32485"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32480"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32478"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32477"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32476"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32472"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32468"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32464"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32453"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32452"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32441"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32440"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32437"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.file-systems.ext4/32436"/>
      </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.ext4/32494">
    <title>nouser_xattr</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32494</link>
    <description>&lt;pre&gt;Hi there,

I have just spotted in my log files that nouser_xattr will be removed.

I think it should be kept in as I currently use that option to ensure
that my / partition (which is on a ssd) is mounted without user_xattr to
stop some writes to it.  If I don't specify nouser_xattr the / partition
automatically gets mounted with user_xattr. 

Will there be any other way to ensure that a partition is mounted
without user_xattr?

(I could have missed something totally obvious tho :P )

Thanks,

Brett
&lt;/pre&gt;</description>
    <dc:creator>Brett M. Royles</dc:creator>
    <dc:date>2012-05-26T11:09:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32493">
    <title>FROM MRS SUSAN SHABANGU(OPEN THE ATTACH FILES)</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32493</link>
    <description>&lt;pre&gt;&lt;/pre&gt;</description>
    <dc:creator>FROM MRS SUSAN SHABANGU</dc:creator>
    <dc:date>2012-05-26T10:56:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32490">
    <title>[PATCH] ext2fs: remove 64-bit wrappers from ext2fs.h</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32490</link>
    <description>&lt;pre&gt;The creation of inline wrappers ext2fs_open() and ext2fs_stat()
in commit c859cb1de0d624caa0779fb17d1a53766143136e in ext2fs.h
caused difficulties with the use of headers, since the headers
for open64() and stat64() may already be included (and skip the
declaration of the 64-bit variants) before ext2fs.h is ever read.
There is no real way to solve the missing prototypes and resulting
compiler warnings inside ext2fs.h.

Since ext2fs_open() and ext2fs_stat() are not performance critical
operations, they do not need to be inline functions at all, and
the needed function headers can be handled properly in one file.

Similarly, posix_memalloc() was having difficulties with headers,
and was being defined in ext2fs.h, but it is now only being used
by a single file, so move the required header there.

Signed-off-by: Andreas Dilger &amp;lt;adilger&amp;lt; at &amp;gt;whamcloud.com&amp;gt;
---
 lib/ext2fs/ext2fs.h  |   46 ----------------------------------------------
 lib/ext2fs/inline.c  |    3 +++
 lib/ext2fs/unix_io.c |   32 ++++++++++++++++++++++++++++++++
 3 files changed, 35 insertions(+), 46 deletions(-)

diff --git a/lib/ext2fs/ext2fs.h b/lib/ext2fs/ext2fs.h
index 9a0e736..ff088bb 100644
--- a/lib/ext2fs/ext2fs.h
+++ b/lib/ext2fs/ext2fs.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -29,10 +29,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; extern "C" {
 #define NO_INLINE_FUNCS
 #endif
 
-#ifndef _XOPEN_SOURCE
-#define _XOPEN_SOURCE 600/* for posix_memalign() */
-#endif
-
 /*
  * Where the master copy of the superblock is located, and how big
  * superblocks are supposed to be.  We define SUPERBLOCK_SIZE because
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -57,16 +53,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; extern "C" {
 #include &amp;lt;stdlib.h&amp;gt;
 #include &amp;lt;string.h&amp;gt;
 #include &amp;lt;errno.h&amp;gt;
-#include &amp;lt;sys/types.h&amp;gt;
-#include &amp;lt;sys/stat.h&amp;gt;
-#include &amp;lt;fcntl.h&amp;gt;
-
-#ifndef __USE_XOPEN2K
-/* If the "#define _XOPEN_SOURCE 600" didn't succeed in declaring
- * posix_memalign(), maybe due to &amp;lt;features.h&amp;gt; or &amp;lt;stdlib.h&amp;gt; included beforej
- * _XOPEN_SOURCE, declare it here to avoid compiler warnings. */
-extern int posix_memalign(void **__memptr, size_t __alignment, size_t __size);
-#endif
 
 #if EXT2_FLAT_INCLUDES
 #include "e2_types.h"
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1709,38 +1695,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; _INLINE_ __u64 ext2fs_div64_ceil(__u64 a, __u64 b)
 return ((a - 1) / b) + 1;
 }
 
-_INLINE_ int ext2fs_open_file(const char *pathname, int flags, mode_t mode)
-{
-if (mode)
-#if defined(HAVE_OPEN64) &amp;amp;&amp;amp; !defined(__OSX_AVAILABLE_BUT_DEPRECATED)
-return open64(pathname, flags, mode);
-else
-return open64(pathname, flags);
-#else
-return open(pathname, flags, mode);
-else
-return open(pathname, flags);
-#endif
-}
-
-_INLINE_ int ext2fs_stat(const char *path, ext2fs_struct_stat *buf)
-{
-#if defined(HAVE_FSTAT64) &amp;amp;&amp;amp; !defined(__OSX_AVAILABLE_BUT_DEPRECATED)
-return stat64(path, buf);
-#else
-return stat(path, buf);
-#endif
-}
-
-_INLINE_ int ext2fs_fstat(int fd, ext2fs_struct_stat *buf)
-{
-#if defined(HAVE_FSTAT64) &amp;amp;&amp;amp; !defined(__OSX_AVAILABLE_BUT_DEPRECATED)
-return fstat64(fd, buf);
-#else
-return fstat(fd, buf);
-#endif
-}
-
 #undef _INLINE_
 #endif
 
diff --git a/lib/ext2fs/inline.c b/lib/ext2fs/inline.c
index 8e66846..eef3dda 100644
--- a/lib/ext2fs/inline.c
+++ b/lib/ext2fs/inline.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -11,6 +11,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
  * %End-Header%
  */
 
+#ifndef _XOPEN_SOURCE
+#define _XOPEN_SOURCE 600/* for posix_memalign() */
+#endif
 
 #include "config.h"
 #include &amp;lt;stdio.h&amp;gt;
diff --git a/lib/ext2fs/unix_io.c b/lib/ext2fs/unix_io.c
index e66b5c8..02570f0 100644
--- a/lib/ext2fs/unix_io.c
+++ b/lib/ext2fs/unix_io.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -435,6 +435,38 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static errcode_t flush_cached_blocks(io_channel channel,
 #endif
 #endif
 
+int ext2fs_open_file(const char *pathname, int flags, mode_t mode)
+{
+if (mode)
+#if defined(HAVE_OPEN64) &amp;amp;&amp;amp; !defined(__OSX_AVAILABLE_BUT_DEPRECATED)
+return open64(pathname, flags, mode);
+else
+return open64(pathname, flags);
+#else
+return open(pathname, flags, mode);
+else
+return open(pathname, flags);
+#endif
+}
+
+int ext2fs_stat(const char *path, ext2fs_struct_stat *buf)
+{
+#if defined(HAVE_FSTAT64) &amp;amp;&amp;amp; !defined(__OSX_AVAILABLE_BUT_DEPRECATED)
+return stat64(path, buf);
+#else
+return stat(path, buf);
+#endif
+}
+
+int ext2fs_fstat(int fd, ext2fs_struct_stat *buf)
+{
+#if defined(HAVE_FSTAT64) &amp;amp;&amp;amp; !defined(__OSX_AVAILABLE_BUT_DEPRECATED)
+return fstat64(fd, buf);
+#else
+return fstat(fd, buf);
+#endif
+}
+
 static errcode_t unix_open(const char *name, int flags, io_channel *channel)
 {
 io_channelio = NULL;
&lt;/pre&gt;</description>
    <dc:creator>Andreas Dilger</dc:creator>
    <dc:date>2012-05-25T22:13:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32488">
    <title>[PATCH] libext2fs: Fix rbtree backend for extent lengths greater than 2^32</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32488</link>
    <description>&lt;pre&gt;Well, this took way too long to find, in retrospect.

In short, for a completely full filesystem with more than 2^32
blocks, the rbtree bitmap backend can assemble an extent of used
blocks which is longer than 2^32.  If it does, it will overflow
-&amp;gt;count, and corrupt the rbtree for the bitmaps.

Discovered by completely filling a 32T filesystem using fallocate, and
then observing debugfs, dumpe2fs, and e2fsck all behaving badly.

(Note that filling with only 31 x 1T files did not show the problem,
because freespace was fragmented enough that there was no sufficiently
long range of used blocks.)

Signed-off-by: Eric Sandeen &amp;lt;sandeen&amp;lt; at &amp;gt;redhat.com&amp;gt;
---

An alternative solution might be to limit the rb_extent to
32-bit counts, and not merging beyond that.  For fragmented
freespace, as normal, perhaps that would be a better memory
savings?  But this fixes the immediate problem and seems worth
merging to avoid bad situations such as e2fsck corrupting a
perfectly good 32T filesystem...

diff --git a/lib/ext2fs/blkmap64_rb.c b/lib/ext2fs/blkmap64_rb.c
index 7ab72f4..a83f8ac 100644
--- a/lib/ext2fs/blkmap64_rb.c
+++ b/lib/ext2fs/blkmap64_rb.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -33,7 +33,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 struct bmap_rb_extent {
 struct rb_node node;
 __u64 start;
-__u32 count;
+__u64 count;
 };
 
 struct ext2fs_rb_private {

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Eric Sandeen</dc:creator>
    <dc:date>2012-05-25T19:43:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32487">
    <title>dm corruption? (Was: Re: can't recover ext4 on lvm from ext4_mb_generate_buddy:739: group 1687, 32254 clusters in bitmap, 32258 in gd)</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32487</link>
    <description>&lt;pre&gt;Hi,

On Thu, Jan 05, 2012 at 11:43:22PM +0100, Sander Eikelenboom wrote:

Has anything else happened with this?

I'm seeing similar problems with dm_crypt (with kernel 3.2.7),
only I also see "JBD2: Spotted dirty metadata buffer",
which I've found some (unanswered) reference to here:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&amp;amp;id=822071

I can reproduce the problem 100% of the time, but only under the
early-boot conditions I see it in. I've failed at any attempt so far to
reproduce it once the system is all the way up. :(

My steps to reproduce are:

create 3G sparse file (making this zero-filled doesn't change anything)
loopback mount file
bring up dm-crypt on loopback
build ext4 on dm-crypt
copy about 100M worth of files into the filesystem

The amount of errors reported varies, but most recently:

[   82.659992] EXT4-fs error (device dm-1): ext4_mb_generate_buddy:739: group 14, 32258 clusters in bitmap, 32262 in gd
[   84.338432] EXT4-fs error (device dm-1): ext4_mb_generate_buddy:739: group 15, 32258 clusters in bitmap, 32262 in gd
[   86.334815] EXT4-fs error (device dm-1): ext4_mb_generate_buddy:739: group 16, 32258 clusters in bitmap, 32262 in gd
[   87.660183] JBD2: Spotted dirty metadata buffer (dev = dm-1, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
[   87.814646] JBD2: Spotted dirty metadata buffer (dev = dm-1, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
[   88.221369] EXT4-fs error (device dm-1): ext4_mb_generate_buddy:739: group 17, 32258 clusters in bitmap, 32262 in gd
[   89.930729] EXT4-fs error (device dm-1): ext4_mb_generate_buddy:739: group 18, 32258 clusters in bitmap, 32262 in gd
[   91.709804] EXT4-fs error (device dm-1): ext4_mb_generate_buddy:739: group 19, 32258 clusters in bitmap, 32262 in gd
[   93.805440] EXT4-fs error (device dm-1): ext4_mb_generate_buddy:739: group 20, 32258 clusters in bitmap, 32262 in gd

I'm at a loss for how to track this down. :(

Any ideas?

-Kees


&lt;/pre&gt;</description>
    <dc:creator>Kees Cook</dc:creator>
    <dc:date>2012-05-25T01:54:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32486">
    <title>[PULL REQUEST] Ext2, ext3 and quota fixes</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32486</link>
    <description>&lt;pre&gt;  Hello Linus,

  could you please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_linus

Interesting bits are:
* removal of a special i_mutex locking subclass
  (I_MUTEX_QUOTA) since quota code does not need i_mutex anymore in any
  unusual way. 
* backport (from ext4) of a fix of a checkpointing bug (missing cache
  flush) that could lead to fs corruption on power failure

The rest are just random small fixes &amp;amp; cleanups.

Top of the tree is 0324876. The full shortlog is:

Akira Fujita (1):
      ext3: remove max_debt in find_group_orlov()

Artem Bityutskiy (2):
      ext2: write superblock only once on unmount
      ext2: do not register write_super within VFS

Eric Sandeen (1):
      ext3: return 32/64-bit dir name hash according to usage type

Jan Kara (12):
      jbd: Refine commit writeout logic
      ext2: Remove s_dirt handling
      jbd: Split updating of journal superblock and marking journal empty
      jbd: protect all log tail updates with j_checkpoint_mutex
      jbd: Write journal superblock with WRITE_FUA after checkpointing
      quota: Fix double lock in add_dquot_ref() with CONFIG_QUOTA_DEBUG
      ext3: Remove i_mutex use from ext3_quota_write()
      ext4: Remove i_mutex use from ext4_quota_write()
      reiserfs: Remove i_mutex use from reiserfs_quota_write()
      ext2: Remove i_mutex use from ext2_quota_write()
      quota: Use precomputed value of sb_dqopt in dquot_quota_sync
      quota: Get rid of nested I_MUTEX_QUOTA locking subclass

Stefan Hajnoczi (1):
      ext3: update documentation with barrier=1 default

Wang Sheng-Hui (2):
      ext2: remove the redundant comment for ext2_export_ops
      ext2: trivial fix to comment for ext2_free_blocks

The diffstat is

 Documentation/filesystems/ext3.txt |    6 +-
 fs/ext2/balloc.c                   |    4 +-
 fs/ext2/ialloc.c                   |    2 -
 fs/ext2/super.c                    |   18 +---
 fs/ext2/xattr.c                    |    1 -
 fs/ext3/dir.c                      |  167 +++++++++++++++++++++--------
 fs/ext3/ext3.h                     |    6 +-
 fs/ext3/hash.c                     |    4 +-
 fs/ext3/ialloc.c                   |   20 +---
 fs/ext3/super.c                    |    6 +-
 fs/ext4/super.c                    |    6 +-
 fs/jbd/checkpoint.c                |   23 ++---
 fs/jbd/commit.c                    |   21 +++-
 fs/jbd/journal.c                   |  206 +++++++++++++++++++++++------------
 fs/jbd/transaction.c               |    2 -
 fs/quota/dquot.c                   |   32 +++---
 fs/reiserfs/super.c                |    6 +-
 include/linux/jbd.h                |   18 ++--
 include/trace/events/jbd.h         |   39 +++----
 19 files changed, 342 insertions(+), 245 deletions(-)

Thanks
Honza
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Jan Kara</dc:creator>
    <dc:date>2012-05-24T23:12:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32485">
    <title>[PATCH] e2fsck: fix checks done for mounted vs. read-only</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32485</link>
    <description>&lt;pre&gt;Currently, if e2fsck is run without the "-n" flag (i.e. it
might modify the filesystem), there is no guarantee that it will
open the filesystem with the EXCLUSIVE flag (i.e. O_EXCL) to
prevent the block device from being checked (in most cases this
means mounted, but it could also be an MD/LVM member device).

Conversely, if e2fsck is run with "-n" (i.e. read-only), and
/etc/mtab or /proc/mounts does not report the block device as
mounted then e2fsck thinks the filesystem is unmounted.  In this
case, e2fsck incorrectly sets the EXCLUSIVE flag, which causes
the check to fail, even though e2fsck is running read-only.

To fix this, do not open with EXCLUSIVE if it is a read-only check,
and always open with EXCLUSIVE if the filesystem might be changed.
This also prevents filesystem mounts while e2fsck is running.

Also refuse allow e2fsck to run at all if the filesystem is BUSY.
The e2fsck check_mount() was checking for MOUNTED, but not BUSY,
and it should refuse to run outright if the block device is BUSY.
The previous MOUNTED heuristics pre-date the O_EXCL reservation
by the kernel, so there could be uncertainty due to stale /etc/mtab
data, but with newer kernels a busy device should never be modified.

Signed-off-by: Andreas Dilger &amp;lt;adilger&amp;lt; at &amp;gt;whamcloud.com&amp;gt;
---
 e2fsck/unix.c |   17 +++++++++--------
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/e2fsck/unix.c b/e2fsck/unix.c
index 53fcd04..6161e46 100644
--- a/e2fsck/unix.c
+++ b/e2fsck/unix.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -219,7 +219,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void check_mount(e2fsck_t ctx)
  * filesystem and it's mounted read-only, and we're not doing
  * a read/write check, then everything's fine.
  */
-if ((!(ctx-&amp;gt;mount_flags &amp;amp; EXT2_MF_MOUNTED)) ||
+if ((!(ctx-&amp;gt;mount_flags &amp;amp; (EXT2_MF_MOUNTED | EXT2_MF_BUSY))) ||
     ((ctx-&amp;gt;mount_flags &amp;amp; EXT2_MF_ISROOT) &amp;amp;&amp;amp;
      (ctx-&amp;gt;mount_flags &amp;amp; EXT2_MF_READONLY) &amp;amp;&amp;amp;
      !(ctx-&amp;gt;options &amp;amp; E2F_OPT_WRITECHECK)))
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -227,13 +227,16 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void check_mount(e2fsck_t ctx)
 
 if ((ctx-&amp;gt;options &amp;amp; E2F_OPT_READONLY) &amp;amp;&amp;amp;
     !(ctx-&amp;gt;options &amp;amp; E2F_OPT_WRITECHECK)) {
-log_out(ctx, _("Warning!  %s is mounted.\n"),
-ctx-&amp;gt;filesystem_name);
+log_out(ctx, _("Warning!  %s is %s.\n"),
+ctx-&amp;gt;filesystem_name,
+ctx-&amp;gt;mount_flags &amp;amp; EXT2_MF_MOUNTED ?
+"mounted" : "in use");
 return;
 }
 
-log_out(ctx, _("%s is mounted.  "), ctx-&amp;gt;filesystem_name);
-if (!ctx-&amp;gt;interactive)
+log_out(ctx, _("%s is %s.\n"), ctx-&amp;gt;filesystem_name,
+ctx-&amp;gt;mount_flags &amp;amp; EXT2_MF_MOUNTED ? "mounted" : "in use");
+if (!ctx-&amp;gt;interactive || ctx-&amp;gt;mount_flags &amp;amp; EXT2_MF_BUSY)
 fatal_error(ctx, _("Cannot continue, aborting.\n\n"));
 puts("\007\007\007\007");
 log_out(ctx, _("\n\nWARNING!!!  "
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1219,9 +1222,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; restart:
 if (!old_bitmaps)
 flags |= EXT2_FLAG_64BITS;
 if ((ctx-&amp;gt;options &amp;amp; E2F_OPT_READONLY) == 0)
-flags |= EXT2_FLAG_RW;
-if ((ctx-&amp;gt;mount_flags &amp;amp; EXT2_MF_MOUNTED) == 0)
-flags |= EXT2_FLAG_EXCLUSIVE;
+flags |= EXT2_FLAG_RW | EXT2_FLAG_EXCLUSIVE;
 
 retval = try_open_fs(ctx, flags, io_ptr, &amp;amp;fs);
 
&lt;/pre&gt;</description>
    <dc:creator>Andreas Dilger</dc:creator>
    <dc:date>2012-05-24T21:34:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32480">
    <title>[PATCH] libe2p: Add JFS_FEATURE_INCOMPAT_64BIT parsing</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32480</link>
    <description>&lt;pre&gt;Today, dumpe2fs for example will give this for a
journal with JFS_FEATURE_INCOMPAT_64BIT:

Journal features:         FEATURE_I1

So fix this to show the more useful:

Journal features:         journal_64bit

Signed-off-by: Eric Sandeen &amp;lt;sandeen&amp;lt; at &amp;gt;redhat.com&amp;gt;
---

diff --git a/lib/e2p/feature.c b/lib/e2p/feature.c
index db85365..9691263 100644
--- a/lib/e2p/feature.c
+++ b/lib/e2p/feature.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -104,6 +104,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static struct feature jrnl_feature_list[] = {
 
        {       E2P_FEATURE_INCOMPAT, JFS_FEATURE_INCOMPAT_REVOKE,
                        "journal_incompat_revoke" },
+       {       E2P_FEATURE_INCOMPAT, JFS_FEATURE_INCOMPAT_64BIT,
+                       "journal_64bit" },
        {       E2P_FEATURE_INCOMPAT, JFS_FEATURE_INCOMPAT_ASYNC_COMMIT,
                        "journal_async_commit" },
        {       0, 0, 0 },

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Eric Sandeen</dc:creator>
    <dc:date>2012-05-24T17:24:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32478">
    <title>[PATCH] ext4: force ro mount if ext3_setup_super() fails</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32478</link>
    <description>&lt;pre&gt;If ext4_setup_super() fails i.e. due to a too-high revision,
the error is logged in dmesg but the fs is not mounted RO as
indicated.

Tested by:

# mkfs.ext4 -r 4 /dev/sdb6
# mount /dev/sdb6 /mnt/test
# dmesg | grep "too high"
[164919.759248] EXT4-fs (sdb6): revision level too high, forcing read-only mode
# grep sdb6 /proc/mounts
/dev/sdb6 /mnt/test2 ext4 rw,seclabel,relatime,data=ordered 0 0
                          ^^

Signed-off-by: Eric Sandeen &amp;lt;sandeen&amp;lt; at &amp;gt;redhat.com&amp;gt;
---

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index e1fb1d5..be67c0b 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -3592,7 +3592,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; no_journal:
 goto failed_mount4;
 }
 
-ext4_setup_super(sb, es, sb-&amp;gt;s_flags &amp;amp; MS_RDONLY);
+if (ext4_setup_super(sb, es, sb-&amp;gt;s_flags &amp;amp; MS_RDONLY))
+sb-&amp;gt;s_flags |= MS_RDONLY;
 
 /* determine the minimum size of new large inodes, if present */
 if (sbi-&amp;gt;s_inode_size &amp;gt; EXT4_GOOD_OLD_INODE_SIZE) {

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Eric Sandeen</dc:creator>
    <dc:date>2012-05-24T17:00:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32477">
    <title>[PATCH] ext3: force ro mount if ext3_setup_super() fails</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32477</link>
    <description>&lt;pre&gt;If ext3_setup_super() fails i.e. due to a too-high revision,
the error is logged in dmesg but the fs is not mounted RO as
indicated.

Tested by:

# mkfs.ext3 -r 4 /dev/sdb6
# mount /dev/sdb6 /mnt/test
# dmesg | grep "too high"
[164152.114551] EXT3-fs (sdb6): error: revision level too high, forcing read-only mode
# grep sdb6 /proc/mounts
/dev/sdb6 /mnt/test2 ext3 rw,seclabel,relatime,errors=continue,user_xattr,acl,barrier=1,data=ordered 0 0
                          ^^

Signed-off-by: Eric Sandeen &amp;lt;sandeen&amp;lt; at &amp;gt;redhat.com&amp;gt;
---

diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index cf0b592..fef7af2 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -2043,7 +2043,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int ext3_fill_super (struct super_block *sb, void *data, int silent)
 goto failed_mount3;
 }
 
-ext3_setup_super (sb, es, sb-&amp;gt;s_flags &amp;amp; MS_RDONLY);
+if (ext3_setup_super(sb, es, sb-&amp;gt;s_flags &amp;amp; MS_RDONLY))
+sb-&amp;gt;s_flags |= MS_RDONLY;
 
 EXT3_SB(sb)-&amp;gt;s_mount_state |= EXT3_ORPHAN_FS;
 ext3_orphan_cleanup(sb, es);

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Eric Sandeen</dc:creator>
    <dc:date>2012-05-24T17:00:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32476">
    <title>[Bug 43292] New: jdb2 lockup with ext3 and nfs</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32476</link>
    <description>&lt;pre&gt;https://bugzilla.kernel.org/show_bug.cgi?id=43292

           Summary: jdb2 lockup with ext3 and nfs
           Product: File System
           Version: 2.5
    Kernel Version: 3.4
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext3
        AssignedTo: fs_ext3&amp;lt; at &amp;gt;kernel-bugs.osdl.org
        ReportedBy: flo&amp;lt; at &amp;gt;xssn.at
        Regression: Yes


When using nfs and writing some files nfsd locks up in D state and I get the
attached backtraces in dmesg. Once nfsd killed the request that triggered the
lockup, the problem will not happen again until the system has been rebooted.
(Tested over a period of 20 days)

I'm not yet sure if it happens on the first write request or only on some
special ones, but I don't really want to reboot my file server and let it hang
that often. However, if you can tell me what to look for or what debugging
features I should use, I'll be happy to try them.

I also didn't yet test if this can be reproduced when writing files directly
(without nfs), but I think it would lock up during boot in that case since I'm
running a mysqld slave on the system.

This started happening around linux 3.2 or 3.3.

I've attached the whole dmesg output (including bootup, in case this is related
to the hardware).

Arch Linux x86_64
Linux 3.4 (config [1])
nfs-utils 1.2.5


[1]:
https://projects.archlinux.org/svntogit/packages.git/plain/trunk/config.x86_64?h=packages/linux&amp;amp;id=f8c396e6ca1e29c3da83431f64074f8c127e1af3

&lt;/pre&gt;</description>
    <dc:creator>bugzilla-daemon&lt; at &gt;bugzilla.kernel.org</dc:creator>
    <dc:date>2012-05-24T15:54:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32472">
    <title>Welcome to the veglrs group</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32472</link>
    <description>&lt;pre&gt;
Hello,

I've added you to my veglrs group at Yahoo! Groups, a free, 
easy-to-use service. Yahoo! Groups makes it easy to send and receive
group messages, coordinate events, share photos and files, and more.


Description of the group:
------------------------------------------------------------------------
jtq42kynn36s05 

Complete your Yahoo! Groups account:
----------------------------------------------------------------------
Your email address has been added to the email list of a Yahoo! Group.
To gain access to all of your group's web features (previous messages,
photos, files, calendar, etc.) and easier control of your message
delivery options, we highly recommend that you complete your account
by connecting your email address to a Yahoo account. It is easy and free.
Please visit:
http://groups.yahoo.com/convacct?email=linux-ext4%40vger.kernel.org&amp;amp;list=veglrs

Important information about the veglrs group
------------------------------------------------------------------------
* To send a message to the members of this group, send an email to:
  veglrs&amp;lt; at &amp;gt;yahoogroups.com 
  
* To leave the group, you can unsubscribe by replying to this message,
  or by sending an email to:
  veglrs-unsubscribe&amp;lt; at &amp;gt;yahoogroups.com 

Regards,

Moderator, veglrs 

Report abuse:
------------------------------------------------------------------------
Because Yahoo! Groups values your privacy, it is a violation of our 
service rules for moderators to add subscribers to a group against
their wishes. If you feel this has happened, please notify us:
http://io.help.yahoo.com/contact/index?locale=en_US&amp;amp;y=PROD_GRPS&amp;amp;page=contact 

You may also change your email preferences to prevent group owners from
adding you to their groups. To do so, please go here:
http://groups.yahoo.com/s?tag=wrR_KnCfsuZ3D_SFqExnqWqIRfqPrBfOVXK_7bF4tIRDix6r0pLtUmP4Kjv6Zjil7GW4CQLOi8Uo4Vc3G1XKmnhgPw9_

Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 



--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>veglrs Moderator</dc:creator>
    <dc:date>2012-05-24T10:38:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32468">
    <title>[PATCH] debugfs: fix strtoblk for 64bit block numbers</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32468</link>
    <description>&lt;pre&gt;# debugfs -R "icheck 4295032832" testimage
debugfs 1.42.3 (14-May-2012)
got block 4295032832 for 4295032832
got block 65536 for 4295032832
BlockInode number
65536&amp;lt;block not found&amp;gt;

Um, that's no good.

Affects icheck, freeb, setb, testb...

Signed-off-by: Eric Sandeen &amp;lt;sandeen&amp;lt; at &amp;gt;redhat.com&amp;gt;
---

diff --git a/debugfs/util.c b/debugfs/util.c
index f43b470..b07a8cc 100644
--- a/debugfs/util.c
+++ b/debugfs/util.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -298,7 +298,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; unsigned long long parse_ulonglong(const char *str, const char *cmd,
  */
 int strtoblk(const char *cmd, const char *str, blk64_t *ret)
 {
-blk_tblk;
+blk64_tblk;
 interr;
 
 blk = parse_ulonglong(str, cmd, "block number", &amp;amp;err);

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Eric Sandeen</dc:creator>
    <dc:date>2012-05-23T23:01:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32464">
    <title>ext4 &gt; 16T woes</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32464</link>
    <description>&lt;pre&gt;I'll try to look into this but just wanted to put it out there.

After creating a 32T fs and filling it with 1T preallocated files,
I get quite a lot of corruption; this wasn't really the test
I wanted to do, I wanted to then remove a file with mostly
high blocks, run fsstress, and test recovery :(

# uname -r
3.4.0-rc4+
# truncate --size 32t imagefile2
# mkfs.ext4 -F imagefile2
mke2fs 1.42.3 (14-May-2012)
...
# mount -o loop imagefile2 /mnt/scratch
# for I in `seq 1 32`; do fallocate -l 1t /mnt/scratch/1tfile$I; done
# umount /mnt/scratch
# time e2fsck -fn imagefile2
e2fsck 1.42.3 (14-May-2012)
&amp;lt;many many many lines snipped&amp;gt;
Free blocks count wrong for group #131072 (0, counted=32768).
Fix? no

Free blocks count wrong for group #131073 (0, counted=32768).
Fix? no

Free blocks count wrong for group #131074 (0, counted=4164).
Fix? no

Free blocks count wrong (3, counted=4294967299).
Fix? no


imagefile2: ********** WARNING: Filesystem still has errors **********

imagefile2: 43/536870912 files (0.0% non-contiguous), 8589934589/8589934592 blocks

real27m40.133s
user27m12.886s
sys0m6.238s

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Eric Sandeen</dc:creator>
    <dc:date>2012-05-23T18:48:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32453">
    <title>[PATCH] libquota: add missing time.h include</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32453</link>
    <description>&lt;pre&gt;This code uses time() but doesn't include time.h leading to:
quotaio.c:89:2: warning: implicit declaration of function 'time'

Signed-off-by: Mike Frysinger &amp;lt;vapier&amp;lt; at &amp;gt;gentoo.org&amp;gt;
---
 lib/quota/quotaio.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lib/quota/quotaio.c b/lib/quota/quotaio.c
index 481d5f5..6e917f0 100644
--- a/lib/quota/quotaio.c
+++ b/lib/quota/quotaio.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -11,6 +11,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 #include &amp;lt;string.h&amp;gt;
 #include &amp;lt;unistd.h&amp;gt;
 #include &amp;lt;stdlib.h&amp;gt;
+#include &amp;lt;time.h&amp;gt;
 #include &amp;lt;sys/types.h&amp;gt;
 #include &amp;lt;sys/stat.h&amp;gt;
 #include &amp;lt;sys/file.h&amp;gt;
&lt;/pre&gt;</description>
    <dc:creator>Mike Frysinger</dc:creator>
    <dc:date>2012-05-22T19:41:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32452">
    <title>[PATCH] libquota: add a quotactl prototype</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32452</link>
    <description>&lt;pre&gt;The commit 0df8a27bbaf51b55c0e8c3a533ef4c2ff9d79c9f removed the system
quota.h include, but in doing so, added the problem:
mkquota.c:55:2: warning: implicit declaration of function 'quotactl'

Since we're maintaining a copy of quota.h, add a proper func prototype.

Signed-off-by: Mike Frysinger &amp;lt;vapier&amp;lt; at &amp;gt;gentoo.org&amp;gt;
---
 lib/quota/quota.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/lib/quota/quota.h b/lib/quota/quota.h
index a943ec6..3eaec1d 100644
--- a/lib/quota/quota.h
+++ b/lib/quota/quota.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -152,4 +152,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; enum {
 };
 #define QUOTA_NL_A_MAX (__QUOTA_NL_A_MAX - 1)
 
+#ifdef HAVE_QUOTACTL
+extern int quotactl(int __cmd, const char *__special, int __id,
+    caddr_t __addr);
+#endif
+
 #endif /* _QUOTA_ */
&lt;/pre&gt;</description>
    <dc:creator>Mike Frysinger</dc:creator>
    <dc:date>2012-05-22T19:41:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32441">
    <title>[PATCH] e2fsck: fix precedence bug in built-in quota support</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32441</link>
    <description>&lt;pre&gt;The operator precedence bug means that we might pay atteion to
s_grp_quota_inum even if the RO_COMPAT_QUOTA feature flag is clear.
However, fortunately, this is unlikely to happen in practice.

Cc: Aditya Kali &amp;lt;adityakali&amp;lt; at &amp;gt;google.com&amp;gt;
Signed-off-by: "Theodore Ts'o" &amp;lt;tytso&amp;lt; at &amp;gt;mit.edu&amp;gt;
---
 e2fsck/pass1.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index c7645d1..c6aae6e 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -928,8 +928,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; void e2fsck_pass1(e2fsck_t ctx)
 ext2fs_mark_inode_bitmap2(ctx-&amp;gt;inode_used_map, ino);
 if ((fs-&amp;gt;super-&amp;gt;s_feature_ro_compat &amp;amp;
 EXT4_FEATURE_RO_COMPAT_QUOTA) &amp;amp;&amp;amp;
-    (fs-&amp;gt;super-&amp;gt;s_usr_quota_inum == ino) ||
-    (fs-&amp;gt;super-&amp;gt;s_grp_quota_inum == ino)) {
+    ((fs-&amp;gt;super-&amp;gt;s_usr_quota_inum == ino) ||
+     (fs-&amp;gt;super-&amp;gt;s_grp_quota_inum == ino))) {
 if (!LINUX_S_ISREG(inode-&amp;gt;i_mode) &amp;amp;&amp;amp;
     fix_problem(ctx, PR_1_QUOTA_BAD_MODE,
 &amp;amp;pctx)) {
&lt;/pre&gt;</description>
    <dc:creator>Theodore Ts'o</dc:creator>
    <dc:date>2012-05-22T02:09:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32440">
    <title>[PATCH] e2fsck: fix 64-bit journal support</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32440</link>
    <description>&lt;pre&gt;
I just found what a somewhat disturbing bug which is still present in
1.42.3 --- namely, that the journal replay code in e2fsck was not
properly handling 64-bit file systems correctly, by dropping the high
bits of the block number from the jbd2 descriptor blocks.

I have not had a chance to fully test to make sure we don't have other
bugs hiding in the 64-bit code, but it's clear no one else has had a lot
of time to test it either -- at least not to the extent of doing power
fail testing of &amp;gt; 16TB file systems!   :-(

- Ted

From 3b693d0b03569795d04920a04a0a21e5f64ffedc Mon Sep 17 00:00:00 2001
From: Theodore Ts'o &amp;lt;tytso&amp;lt; at &amp;gt;mit.edu&amp;gt;
Date: Mon, 21 May 2012 21:30:45 -0400
Subject: [PATCH] e2fsck: fix 64-bit journal support

64-bit journal support was broken; we weren't using the high bits from
the journal descriptor blocks!  We were also using "unsigned long" for
the journal block numbers, which would be a problem on 32-bit systems.

Signed-off-by: "Theodore Ts'o" &amp;lt;tytso&amp;lt; at &amp;gt;mit.edu&amp;gt;
---
 e2fsck/jfs_user.h |    4 ++--
 e2fsck/journal.c  |   33 +++++++++++++++++----------------
 e2fsck/recovery.c |   25 ++++++++++++-------------
 3 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/e2fsck/jfs_user.h b/e2fsck/jfs_user.h
index 9e33306..92f8ae2 100644
--- a/e2fsck/jfs_user.h
+++ b/e2fsck/jfs_user.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -18,7 +18,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct buffer_head {
 e2fsck_tb_ctx;
 io_channel b_io;
 int b_size;
-blk_t b_blocknr;
+unsigned long long b_blocknr;
 int b_dirty;
 int b_uptodate;
 int b_err;
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -121,7 +121,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; _INLINE_ size_t journal_tag_bytes(journal_t *journal)
 /*
  * Kernel compatibility functions are defined in journal.c
  */
-int journal_bmap(journal_t *journal, blk64_t block, unsigned long *phys);
+int journal_bmap(journal_t *journal, blk64_t block, unsigned long long *phys);
 struct buffer_head *getblk(kdev_t ctx, blk64_t blocknr, int blocksize);
 void sync_blockdev(kdev_t kdev);
 void ll_rw_block(int rw, int dummy, struct buffer_head *bh[]);
diff --git a/e2fsck/journal.c b/e2fsck/journal.c
index 915b8bb..bada028 100644
--- a/e2fsck/journal.c
+++ b/e2fsck/journal.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -44,7 +44,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int bh_count = 0;
  * to use the recovery.c file virtually unchanged from the kernel, so we
  * don't have to do much to keep kernel and user recovery in sync.
  */
-int journal_bmap(journal_t *journal, blk64_t block, unsigned long *phys)
+int journal_bmap(journal_t *journal, blk64_t block, unsigned long long *phys)
 {
 #ifdef USE_INODE_IO
 *phys = block;
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -80,8 +80,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct buffer_head *getblk(kdev_t kdev, blk64_t blocknr, int blocksize)
 if (journal_enable_debug &amp;gt;= 3)
 bh_count++;
 #endif
-jfs_debug(4, "getblk for block %lu (%d bytes)(total %d)\n",
-  (unsigned long) blocknr, blocksize, bh_count);
+jfs_debug(4, "getblk for block %llu (%d bytes)(total %d)\n",
+  (unsigned long long) blocknr, blocksize, bh_count);
 
 bh-&amp;gt;b_ctx = kdev-&amp;gt;k_ctx;
 if (kdev-&amp;gt;k_dev == K_DEV_FS)
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -114,38 +114,39 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; void ll_rw_block(int rw, int nr, struct buffer_head *bhp[])
 for (; nr &amp;gt; 0; --nr) {
 bh = *bhp++;
 if (rw == READ &amp;amp;&amp;amp; !bh-&amp;gt;b_uptodate) {
-jfs_debug(3, "reading block %lu/%p\n",
-  (unsigned long) bh-&amp;gt;b_blocknr, (void *) bh);
+jfs_debug(3, "reading block %llu/%p\n",
+  bh-&amp;gt;b_blocknr, (void *) bh);
 retval = io_channel_read_blk64(bh-&amp;gt;b_io,
      bh-&amp;gt;b_blocknr,
      1, bh-&amp;gt;b_data);
 if (retval) {
 com_err(bh-&amp;gt;b_ctx-&amp;gt;device_name, retval,
-"while reading block %lu\n",
-(unsigned long) bh-&amp;gt;b_blocknr);
+"while reading block %llu\n",
+bh-&amp;gt;b_blocknr);
 bh-&amp;gt;b_err = retval;
 continue;
 }
 bh-&amp;gt;b_uptodate = 1;
 } else if (rw == WRITE &amp;amp;&amp;amp; bh-&amp;gt;b_dirty) {
-jfs_debug(3, "writing block %lu/%p\n",
-  (unsigned long) bh-&amp;gt;b_blocknr, (void *) bh);
+jfs_debug(3, "writing block %llu/%p\n",
+  bh-&amp;gt;b_blocknr,
+  (void *) bh);
 retval = io_channel_write_blk64(bh-&amp;gt;b_io,
       bh-&amp;gt;b_blocknr,
       1, bh-&amp;gt;b_data);
 if (retval) {
 com_err(bh-&amp;gt;b_ctx-&amp;gt;device_name, retval,
-"while writing block %lu\n",
-(unsigned long) bh-&amp;gt;b_blocknr);
+"while writing block %llu\n",
+bh-&amp;gt;b_blocknr);
 bh-&amp;gt;b_err = retval;
 continue;
 }
 bh-&amp;gt;b_dirty = 0;
 bh-&amp;gt;b_uptodate = 1;
 } else {
-jfs_debug(3, "no-op %s for block %lu\n",
+jfs_debug(3, "no-op %s for block %llu\n",
   rw == READ ? "read" : "write",
-  (unsigned long) bh-&amp;gt;b_blocknr);
+  bh-&amp;gt;b_blocknr);
 }
 }
 }
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -164,8 +165,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; void brelse(struct buffer_head *bh)
 {
 if (bh-&amp;gt;b_dirty)
 ll_rw_block(WRITE, 1, &amp;amp;bh);
-jfs_debug(3, "freeing block %lu/%p (total %d)\n",
-  (unsigned long) bh-&amp;gt;b_blocknr, (void *) bh, --bh_count);
+jfs_debug(3, "freeing block %llu/%p (total %d)\n",
+  bh-&amp;gt;b_blocknr, (void *) bh, --bh_count);
 ext2fs_free_mem(&amp;amp;bh);
 }
 
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -237,7 +238,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static errcode_t e2fsck_get_journal(e2fsck_t ctx, journal_t **ret_journal)
 journal_t*journal = NULL;
 errcode_tretval = 0;
 io_managerio_ptr = 0;
-unsigned longstart = 0;
+unsigned long longstart = 0;
 intext_journal = 0;
 inttried_backup_jnl = 0;
 
diff --git a/e2fsck/recovery.c b/e2fsck/recovery.c
index b669941..e94ef4e 100644
--- a/e2fsck/recovery.c
+++ b/e2fsck/recovery.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -71,7 +71,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int do_readahead(journal_t *journal, unsigned int start)
 {
 int err;
 unsigned int max, nbufs, next;
-unsigned long blocknr;
+unsigned long long blocknr;
 struct buffer_head *bh;
 
 struct buffer_head * bufs[MAXBUF];
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -133,7 +133,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int jread(struct buffer_head **bhp, journal_t *journal,
  unsigned int offset)
 {
 int err;
-unsigned long blocknr;
+unsigned long long blocknr;
 struct buffer_head *bh;
 
 *bhp = NULL;
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -309,7 +309,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int journal_skip_recovery(journal_t *journal)
 return err;
 }
 
-#if 0
 static inline unsigned long long read_tag_block(int tag_bytes, journal_block_tag_t *tag)
 {
 unsigned long long block = be32_to_cpu(tag-&amp;gt;t_blocknr);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -317,17 +316,16 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static inline unsigned long long read_tag_block(int tag_bytes, journal_block_tag
 block |= (__u64)be32_to_cpu(tag-&amp;gt;t_blocknr_high) &amp;lt;&amp;lt; 32;
 return block;
 }
-#endif
 
 /*
  * calc_chksums calculates the checksums for the blocks described in the
  * descriptor block.
  */
 static int calc_chksums(journal_t *journal, struct buffer_head *bh,
-unsigned long *next_log_block, __u32 *crc32_sum)
+unsigned long long *next_log_block, __u32 *crc32_sum)
 {
 int i, num_blks, err;
-unsigned long io_block;
+unsigned long long io_block;
 struct buffer_head *obh;
 
 num_blks = count_tags(journal, bh);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -340,7 +338,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int calc_chksums(journal_t *journal, struct buffer_head *bh,
 err = jread(&amp;amp;obh, journal, io_block);
 if (err) {
 printk(KERN_ERR "JBD: IO error %d recovering block "
-"%lu in log\n", err, io_block);
+"%llu in log\n", err, io_block);
 return 1;
 } else {
 *crc32_sum = crc32_be(*crc32_sum, (void *)obh-&amp;gt;b_data,
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -355,7 +353,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int do_one_pass(journal_t *journal,
 struct recovery_info *info, enum passtype pass)
 {
 unsigned intfirst_commit_ID, next_commit_ID;
-unsigned longnext_log_block;
+unsigned long longnext_log_block;
 interr, success = 0;
 journal_superblock_t *sb;
 journal_header_t *tmp;
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -485,7 +483,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int do_one_pass(journal_t *journal,
 tagp = &amp;amp;bh-&amp;gt;b_data[sizeof(journal_header_t)];
 while ((tagp - bh-&amp;gt;b_data + tag_bytes)
        &amp;lt;= journal-&amp;gt;j_blocksize) {
-unsigned long io_block;
+unsigned long long io_block;
 
 tag = (journal_block_tag_t *) tagp;
 flags = be32_to_cpu(tag-&amp;gt;t_flags);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -499,13 +497,14 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int do_one_pass(journal_t *journal,
 success = err;
 printk (KERN_ERR
 "JBD: IO error %d recovering "
-"block %ld in log\n",
+"block %llu in log\n",
 err, io_block);
 } else {
-unsigned long blocknr;
+unsigned long long blocknr;
 
 J_ASSERT(obh != NULL);
-blocknr = be32_to_cpu(tag-&amp;gt;t_blocknr);
+blocknr = read_tag_block(tag_bytes,
+ tag);
 
 /* If the block has been
  * revoked, then we're all done
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -733,7 +732,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int scan_revoke_records(journal_t *journal, struct buffer_head *bh,
 record_len = 8;
 
 while (offset &amp;lt; max) {
-unsigned long blocknr;
+unsigned long long blocknr;
 int err;
 
 if (record_len == 4)
&lt;/pre&gt;</description>
    <dc:creator>Theodore Ts'o</dc:creator>
    <dc:date>2012-05-22T01:42:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32437">
    <title>[PATCH] ext4: enable the 64-bit jbd2 feature based on the 64-bit ext4 feature</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32437</link>
    <description>&lt;pre&gt;Previously we were only enabling the 64-bit jbd2 feature if the number
of blocks in the file system was greater 2**32-1.  The problem with
this is that it makes it harder to test the 64-bit journal code paths
with small file systems, since a small test file system would with the
64-bit ext4 feature enable would use a 64-bit file system on-disk data
structures, but use a 32-bit journal.

This would also cause problems when trying to do an online resize to
grow the filesystem above the 2**32-1 boundary.  Fortunately the patch
to support online resize for 64-bit file systems hasn't been merged
yet, so this problem hasn't arisen in practice.

Signed-off-by: "Theodore Ts'o" &amp;lt;tytso&amp;lt; at &amp;gt;mit.edu&amp;gt;
---
 fs/ext4/super.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index c18c596..88c2054 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -3603,7 +3603,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int ext4_fill_super(struct super_block *sb, void *data, int silent)
 goto no_journal;
 }
 
-if (ext4_blocks_count(es) &amp;gt; 0xffffffffULL &amp;amp;&amp;amp;
+if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_64BIT) &amp;amp;&amp;amp;
     !jbd2_journal_set_features(EXT4_SB(sb)-&amp;gt;s_journal, 0, 0,
        JBD2_FEATURE_INCOMPAT_64BIT)) {
 ext4_msg(sb, KERN_ERR, "Failed to set 64-bit journal feature");
&lt;/pre&gt;</description>
    <dc:creator>Theodore Ts'o</dc:creator>
    <dc:date>2012-05-21T15:42:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32436">
    <title>[PATCH] jbd2: use kmem_cache_zalloc wrapper instead of flag</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32436</link>
    <description>&lt;pre&gt;Use kmem_cache_zalloc wrapper instead of flag __GFP_ZERO.

Signed-off-by: Wanlong Gao &amp;lt;gaowanlong&amp;lt; at &amp;gt;cn.fujitsu.com&amp;gt;
---
 fs/jbd2/transaction.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index ddcd354..fb1ab953 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -162,8 +162,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int start_this_handle(journal_t *journal, handle_t *handle,
 
 alloc_transaction:
 if (!journal-&amp;gt;j_running_transaction) {
-new_transaction = kmem_cache_alloc(transaction_cache,
-   gfp_mask | __GFP_ZERO);
+new_transaction = kmem_cache_zalloc(transaction_cache,
+    gfp_mask);
 if (!new_transaction) {
 /*
  * If __GFP_FS is not present, then we may be
&lt;/pre&gt;</description>
    <dc:creator>Wanlong Gao</dc:creator>
    <dc:date>2012-05-21T13:19:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.file-systems.ext4/32435">
    <title>Order Enquiry</title>
    <link>http://comments.gmane.org/gmane.comp.file-systems.ext4/32435</link>
    <description>&lt;pre&gt;
Hello Sales
     I went over your contact online and found some items which we have interest in purchasing to our store in Spain for urgent supply. I will like to know the prices per each items plus the shipping cost. I also want to know if Letter of Credit or T/T is acceptable for payment. I await your quick response asap so i can proceed with my needed items and quantity.

Thank you
mcckoy robertson


N.B.M Global Supply Inc
Address: Autovía A-5,
salidas 22 y 26.
Arroyomolinos,
28939 Madrid Spain
Tel: +34 902 26 77 26
Email: nbmglobalsupply&amp;lt; at &amp;gt;gmail.com
Website : http://www.brplastics.com


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Mcckoy Robertson</dc:creator>
    <dc:date>2012-05-20T15:36:08</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.file-systems.ext4">
    <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.ext4</link>
  </textinput>
</rdf:RDF>

