gmane.comp.file-systems.ext4

[PATCH] ext2fs: remove 64-bit wrappers from ext2fs.h

Andreas Dilger — 2012-05-25T22:13:54

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 <adilger< at >whamcloud.com>
---
 lib/ext2fs/ext2fs.h  |   46 ----------------------------------------------
 lib/ext2fs/inline.c  |    3 +++
 lib/ext2fs/unix_io.c |   32 ++++++++++++++++++++++

Re: ext4 > 16T woes

Eric Sandeen — 2012-05-25T21:01:55

FWIW I tracked this down to the rbtree bitmap backend and sent
a patch,

[PATCH] libext2fs: Fix rbtree backend for extent lengths greater than 2^32

-Eric


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

[PATCH] libext2fs: Fix rbtree backend for extent lengths greater than 2^32

Eric Sandeen — 2012-05-25T19:43:53

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
->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 <sandeen< at >redhat.com>
---

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/blkmap6

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)

Kees Cook — 2012-05-25T01:54:17

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&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

[PULL REQUEST] Ext2, ext3 and quota fixes

Jan Kara — 2012-05-24T23:12:09

  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 & 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

[PATCH] e2fsck: fix checks done for mounted vs. read-only

Andreas Dilger — 2012-05-24T21:34:56

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

Re: [PATCH] ext3: force ro mount if ext3_setup_super() fails

Andreas Dilger — 2012-05-24T17:41:57

Reviewed-by: Andreas Dilger <adilger< at >whamcloud.com>


I was wondering if this should be:

sb->s_flags |= ext3_setup_super(...)

but that might be over-thinking things.



Cheers, Andreas





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

Re: [PATCH] ext4: force ro mount if ext3_setup_super() fails

Andreas Dilger — 2012-05-24T17:30:54

Reviewed-by: Andreas Dilger <adilger< at >whamcloud.com>



Cheers, Andreas





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

Re: [PATCH V2] ext4: force ro mount if ext4_setup_super() fails

Andreas Dilger — 2012-05-24T17:30:24

Reviewed-by: Andreas Dilger <adilger< at >whamcloud.com>



Cheers, Andreas





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

Re: [PATCH] libe2p: Add JFS_FEATURE_INCOMPAT_64BIT parsing

Eric Sandeen — 2012-05-24T17:30:05

Oh, I see that this already got committed into the maint branch.

Nevermind.


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

[PATCH] libe2p: Add JFS_FEATURE_INCOMPAT_64BIT parsing

Eric Sandeen — 2012-05-24T17:24:49

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 <sandeen< at >redhat.com>
---

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
< at >< at > -104,6 +104,8 < at >< at > 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< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-

[PATCH V2] ext4: force ro mount if ext4_setup_super() fails

Eric Sandeen — 2012-05-24T17:01:43

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 <sandeen< at >redhat.com>
---

V2, fix subject C&P error, oops.

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
< at >< at > -3592,7 +3592,8 < at >< at > no_journal:
 goto failed_mount4;
 }
 
-ext4_setup_super(sb, es, sb->s_flags & MS_RDONLY);
+if (ext4_setup_super(sb, es, sb->s_flags & MS_RDONLY))
+sb->s_flags |= MS_RDONLY;
 
 /* determine the minimum size of new large inodes, if present */
 if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE) {

--
To unsubscribe from this list: send the line "unsubscribe l

[PATCH] ext4: force ro mount if ext3_setup_super() fails

Eric Sandeen — 2012-05-24T17:00:47

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 <sandeen< at >redhat.com>
---

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
< at >< at > -3592,7 +3592,8 < at >< at > no_journal:
 goto failed_mount4;
 }
 
-ext4_setup_super(sb, es, sb->s_flags & MS_RDONLY);
+if (ext4_setup_super(sb, es, sb->s_flags & MS_RDONLY))
+sb->s_flags |= MS_RDONLY;
 
 /* determine the minimum size of new large inodes, if present */
 if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE) {

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a messag

[PATCH] ext3: force ro mount if ext3_setup_super() fails

Eric Sandeen — 2012-05-24T17:00:37

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 <sandeen< at >redhat.com>
---

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
< at >< at > -2043,7 +2043,8 < at >< at > static int ext3_fill_super (struct super_block *sb, void *data, int silent)
 goto failed_mount3;
 }
 
-ext3_setup_super (sb, es, sb->s_flags & MS_RDONLY);
+if (ext3_setup_super(sb, es, sb->s_flags & MS_RDONLY))
+sb->s_flags |= MS_RDONLY;
 
 EXT3_SB(sb)->s_mount_state |= EXT3_ORPHAN_FS;
 ext3_orphan_cleanup(sb, es);

--
To unsubscribe from th

[Bug 43292] New: jdb2 lockup with ext3 and nfs

2012-05-24T15:54:30

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< at >kernel-bugs.osdl.org
        ReportedBy: flo< at >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 did

[Bug 16583] ext4: delayed block allocation failed and application not respond any more

2012-05-24T13:13:00

https://bugzilla.kernel.org/show_bug.cgi?id=16583


Loredan Stancu <salecss< at >gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |salecss< at >gmail.com




--- Comment #1 from Loredan Stancu <salecss< at >gmail.com>  2012-05-24 13:13:00 ---
Hi guys,

Any new on this? I just had the same problem with the ext4 file system after
resizing it from a LVM.

I'm using RHEL 6.3, kernel 2.6.32-262.el6.x86_64.

What I did was to:

1. Umount the LVM partion
2. check it with fsck.ext4 tool (no errors reported)
3. resize the file system using resize2fs tool (no errors reported)
4. resize the LVM using lvresize tool (no error reported)
5. run fsck.ext4 for the resulted file system and no errors was reported.

I was able to mount the new file system but when trying to use db2 database
from that partition I received the following file system error and db2 instance
crashed suddenly:

EXT4-

Re: [PATCH 01/10] string: introduce memweight

Akinobu Mita — 2012-05-24T11:54:16

2012/5/23 Matthew Wilcox <matthew< at >wil.cx>:

I just use the same type as the bytes argument without mature
consideration.  If unsigned long is better than size_t, I'll
change the return type.


This works perfectly on little-endian machines.  But it doesn't work
on big-endian machines, if the bottom edge of memory area is not
aligned on long word boundary.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Welcome to the veglrs group

veglrs Moderator — 2012-05-24T10:38:29

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&list=veglrs

Important information about the veglrs group
------------------------------------------------------------------------
* To send a message to th

[Bug 43260] ftruncate locks up when used with direct IO on ext4

2012-05-24T10:16:57

https://bugzilla.kernel.org/show_bug.cgi?id=43260


Jan Kara <jack< at >suse.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jack< at >suse.cz




--- Comment #3 from Jan Kara <jack< at >suse.cz>  2012-05-24 10:16:57 ---
Hum, I see. So we are holding i_mutex and waiting for dio to finish and worker
thread cannot take i_mutex to finish the extent conversion and call
inode_dio_done(). Slightly subtle is that the worker tries to be clever and if
it cannot acquire i_mutex, it requeues the work item so it does not really
deadlock the system, it just eats up CPU cycling the work over and over...

I'm uncertain how to best fix this. If we just revert 266991b13, we reintroduce
the problem of AIO DIO completion racing with truncate (so extent conversion
would happen on already freed blocks). But I'm thinking that with DIO vs
truncate protection in VFS, we probably don't need i_mutex for

[Bug 16019] Resume from hibernate corrupts ext4

2012-05-24T07:34:11

https://bugzilla.kernel.org/show_bug.cgi?id=16019


Zhang Rui <rui.zhang< at >intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |CLOSED
         Resolution|                            |INSUFFICIENT_DATA




--- Comment #49 from Zhang Rui <rui.zhang< at >intel.com>  2012-05-24 07:34:11 ---
bug closed as there is no response from the bug reporter.
please feel free to reopen it if the problem still exists in the latest
upstream kernel.

Re: [PATCH] e2fsck: fix 64-bit journal support

Andreas Dilger — 2012-05-24T01:00:40

Ted, were you going to push this patch?  I didn't see it in the maint branch where the other post-1.42.3 patches were. 

Cheers, Andreas

On 2012-05-21, at 19:42, "Theodore Ts'o" <tytso< at >mit.edu> wrote:

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