http://blog.gmane.org/gmane.comp.file-systems.ext4 hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.file-systems.ext4/32494 <pre>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 </pre> Brett M. Royles 2012-05-26T11:09:46 http://comments.gmane.org/gmane.comp.file-systems.ext4/32493 <pre></pre> FROM MRS SUSAN SHABANGU 2012-05-26T10:56:23 http://comments.gmane.org/gmane.comp.file-systems.ext4/32490 <pre>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 &lt;adilger&lt; at &gt;whamcloud.com&gt; --- lib/ext2fs/ext2fs.h | 46 ---------------------------------------------- lib/ext2fs/inline.c | 3 +++ lib/ext2fs/unix_io.c | 32 ++++++++++++++++++++++</pre> Andreas Dilger 2012-05-25T22:13:54 http://comments.gmane.org/gmane.comp.file-systems.ext4/32488 <pre>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 -&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 &lt;sandeen&lt; at &gt;redhat.com&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/blkmap6</pre> Eric Sandeen 2012-05-25T19:43:53 http://comments.gmane.org/gmane.comp.file-systems.ext4/32487 <pre>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;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 </pre> Kees Cook 2012-05-25T01:54:17 http://comments.gmane.org/gmane.comp.file-systems.ext4/32486 <pre> 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; 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 </pre> Jan Kara 2012-05-24T23:12:09 http://comments.gmane.org/gmane.comp.file-systems.ext4/32485 <pre>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 </pre> Andreas Dilger 2012-05-24T21:34:56 http://comments.gmane.org/gmane.comp.file-systems.ext4/32480 <pre>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 &lt;sandeen&lt; at &gt;redhat.com&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 &lt; at &gt;&lt; at &gt; -104,6 +104,8 &lt; at &gt;&lt; at &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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-</pre> Eric Sandeen 2012-05-24T17:24:49 http://comments.gmane.org/gmane.comp.file-systems.ext4/32478 <pre>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 &lt;sandeen&lt; at &gt;redhat.com&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 &lt; at &gt;&lt; at &gt; -3592,7 +3592,8 &lt; at &gt;&lt; at &gt; no_journal: goto failed_mount4; } -ext4_setup_super(sb, es, sb-&gt;s_flags &amp; MS_RDONLY); +if (ext4_setup_super(sb, es, sb-&gt;s_flags &amp; MS_RDONLY)) +sb-&gt;s_flags |= MS_RDONLY; /* determine the minimum size of new large inodes, if present */ if (sbi-&gt;s_inode_size &gt; EXT4_GOOD_OLD_INODE_SIZE) { -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a messag</pre> Eric Sandeen 2012-05-24T17:00:47 http://comments.gmane.org/gmane.comp.file-systems.ext4/32477 <pre>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 &lt;sandeen&lt; at &gt;redhat.com&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 &lt; at &gt;&lt; at &gt; -2043,7 +2043,8 &lt; at &gt;&lt; at &gt; static int ext3_fill_super (struct super_block *sb, void *data, int silent) goto failed_mount3; } -ext3_setup_super (sb, es, sb-&gt;s_flags &amp; MS_RDONLY); +if (ext3_setup_super(sb, es, sb-&gt;s_flags &amp; MS_RDONLY)) +sb-&gt;s_flags |= MS_RDONLY; EXT3_SB(sb)-&gt;s_mount_state |= EXT3_ORPHAN_FS; ext3_orphan_cleanup(sb, es); -- To unsubscribe from th</pre> Eric Sandeen 2012-05-24T17:00:37 http://comments.gmane.org/gmane.comp.file-systems.ext4/32476 <pre>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&lt; at &gt;kernel-bugs.osdl.org ReportedBy: flo&lt; at &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 did</pre> bugzilla-daemon< at >bugzilla.kernel.org 2012-05-24T15:54:30 http://comments.gmane.org/gmane.comp.file-systems.ext4/32472 <pre> 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;list=veglrs Important information about the veglrs group ------------------------------------------------------------------------ * To send a message to th</pre> veglrs Moderator 2012-05-24T10:38:29 http://comments.gmane.org/gmane.comp.file-systems.ext4/32468 <pre># 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&lt;block not found&gt; Um, that's no good. Affects icheck, freeb, setb, testb... Signed-off-by: Eric Sandeen &lt;sandeen&lt; at &gt;redhat.com&gt; --- diff --git a/debugfs/util.c b/debugfs/util.c index f43b470..b07a8cc 100644 --- a/debugfs/util.c +++ b/debugfs/util.c &lt; at &gt;&lt; at &gt; -298,7 +298,7 &lt; at &gt;&lt; at &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;err); -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Eric Sandeen 2012-05-23T23:01:14 http://comments.gmane.org/gmane.comp.file-systems.ext4/32464 <pre>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) &lt;many many many lines snipped&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-conti</pre> Eric Sandeen 2012-05-23T18:48:34 http://comments.gmane.org/gmane.comp.file-systems.ext4/32453 <pre>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 &lt;vapier&lt; at &gt;gentoo.org&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 &lt; at &gt;&lt; at &gt; -11,6 +11,7 &lt; at &gt;&lt; at &gt; #include &lt;string.h&gt; #include &lt;unistd.h&gt; #include &lt;stdlib.h&gt; +#include &lt;time.h&gt; #include &lt;sys/types.h&gt; #include &lt;sys/stat.h&gt; #include &lt;sys/file.h&gt; </pre> Mike Frysinger 2012-05-22T19:41:50 http://comments.gmane.org/gmane.comp.file-systems.ext4/32452 <pre>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 &lt;vapier&lt; at &gt;gentoo.org&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 &lt; at &gt;&lt; at &gt; -152,4 +152,9 &lt; at &gt;&lt; at &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_ */ </pre> Mike Frysinger 2012-05-22T19:41:29 http://comments.gmane.org/gmane.comp.file-systems.ext4/32441 <pre>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 &lt;adityakali&lt; at &gt;google.com&gt; Signed-off-by: "Theodore Ts'o" &lt;tytso&lt; at &gt;mit.edu&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 &lt; at &gt;&lt; at &gt; -928,8 +928,8 &lt; at &gt;&lt; at &gt; void e2fsck_pass1(e2fsck_t ctx) ext2fs_mark_inode_bitmap2(ctx-&gt;inode_used_map, ino); if ((fs-&gt;super-&gt;s_feature_ro_compat &amp; EXT4_FEATURE_RO_COMPAT_QUOTA) &amp;&amp; - (fs-&gt;super-&gt;s_usr_quota_inum == ino) || - (fs-&gt;super-&gt;s_grp_quota_inum == ino)) { + ((fs-&gt;super-&gt;s_usr_quota_inum == ino) || + (fs-&gt;super-&gt;s_grp_quota_inum == ino))) { if (!LINUX_S_ISREG(inode-&gt;i_mode) &amp;&amp; fix_problem(ctx, PR_1_QUOTA_BAD_MODE, &amp;pctx)) { </pre> Theodore Ts'o 2012-05-22T02:09:34 http://comments.gmane.org/gmane.comp.file-systems.ext4/32440 <pre> 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 &gt; 16TB file systems! :-( - Ted From 3b693d0b03569795d04920a04a0a21e5f64ffedc Mon Sep 17 00:00:00 2001 From: Theodore Ts'o &lt;tytso&lt; at &gt;mit.edu&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" &lt;tytso&lt; at &gt;mit.edu&gt; --- e2fsck/jfs_user.h | </pre> Theodore Ts'o 2012-05-22T01:42:15 http://comments.gmane.org/gmane.comp.file-systems.ext4/32437 <pre>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" &lt;tytso&lt; at &gt;mit.edu&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 &lt; at &gt;&lt; at &gt; -3603,7 +3603,7 &lt; at &gt;&lt; at &gt; static int ext4_fill_super(struct super_block *sb, void *data, int silent) goto no_journal; } -if (</pre> Theodore Ts'o 2012-05-21T15:42:50 http://comments.gmane.org/gmane.comp.file-systems.ext4/32436 <pre>Use kmem_cache_zalloc wrapper instead of flag __GFP_ZERO. Signed-off-by: Wanlong Gao &lt;gaowanlong&lt; at &gt;cn.fujitsu.com&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 &lt; at &gt;&lt; at &gt; -162,8 +162,8 &lt; at &gt;&lt; at &gt; static int start_this_handle(journal_t *journal, handle_t *handle, alloc_transaction: if (!journal-&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 </pre> Wanlong Gao 2012-05-21T13:19:48 http://comments.gmane.org/gmane.comp.file-systems.ext4/32435 <pre> 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&lt; at &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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Mcckoy Robertson 2012-05-20T15:36:08 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.file-systems.ext4