http://permalink.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://permalink.gmane.org/gmane.comp.file-systems.ext4/39224 <pre> Hi Dave, Thank you for pointing that out, I was not aware of that. I know that the 5M tests may be a bit too extreme. I thought it might be interesting to see what happens. Lukas is right, these are the scripts I used to get the results above and they're up-to-date. If you'd like to run the tests, there are some parameters you will probably need to adjust in the run_tests.sh file. Namely: DEVICE - that's the testing device DROP_OFF_DIR - this is a scratch dir for the copy test, which should reside on a separate device RESULTS_DIR - this is where you want your graphs to be stored FILESYSTEMS - ext4, btrfs, jfs or xfs. If you would like to change the parameters of mkfs, you can do it here: https://github.com/astro-/dir-index-test/blob/master/scripts/prepfs.sh FSIZES - the size of each file in the directory (if you provide a list of values, the tests will be run multiple times with different file sizes) TEST_CASES </pre> Radek Pazdera 2013-06-19T12:10:20 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39222 <pre>It is possible to have a flex_bg filesystem with block groups which have inode &amp; block bitmaps at some point well past the start of the group. If an offline shrink puts the new size somewhere between the start of the block group and the (old) location of the bitmaps, they can be left beyond the end of the filesystem, i.e. result in fs corruption. Check each remaining block group for whether its bitmaps are beyond the end of the new filesystem, and reallocate them in a new location if needed. Signed-off-by: Eric Sandeen &lt;sandeen&lt; at &gt;redhat.com&gt; --- I have no idea if this is the right approach or not ;) diff --git a/resize/resize2fs.c b/resize/resize2fs.c index aa2364c..263dea1 100644 --- a/resize/resize2fs.c +++ b/resize/resize2fs.c &lt; at &gt;&lt; at &gt; -854,6 +854,7 &lt; at &gt;&lt; at &gt; static errcode_t blocks_to_move(ext2_resize_t rfs) dgrp_ti, max_groups, g; blk64_tblk, group_blk; blk64_told_blocks, new_blocks; +blk64_tnew_size; unsigned intmeta_bg, meta_bg_size; errcode_tretval; ext2_filsys fs, old_fs; &lt; at &gt;&lt; at &gt; -882,6 +88</pre> Eric Sandeen 2013-06-19T01:37:05 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39221 <pre>This fs image is problematic for offline resize2fs shrink. (sorry, it expands to 11G) # resize2fs &lt;image&gt; 2507776 will lead to corruption[1] because the new size is in the middle of a block group which has its inode &amp; block bitmaps towards the end; the bitmaps are left beyond the end of the new filesystem. I've been trying to find my way around resize2fs, but bleah, I must admit to being perpetually lost. I'm not sure there's any simple functionality to handle this case; does anything else ever need to move bitmaps? I was looking at blocks_to_move(), and within the "shrinking" loop I added logic to detect this case: /* If this (first) group will remain but bitmaps are past EOF, move them */ if (g == ext2fs_group_of_blk2(fs, ext2fs_blocks_count(fs-&gt;super))) { int retval; blk64_t new_size = ext2fs_blocks_count(fs-&gt;super); if ((IS_BLOCK_BM(fs, g, blk) || IS_INODE_BM(fs, g, blk)) &amp;&amp; </pre> Eric Sandeen 2013-06-19T00:24:36 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39218 <pre> Seems to do about the same as http://patchwork.ozlabs.org/patch/243542/ so... Reviewed-by: Darrick J. Wong &lt;darrick.wong&lt; at &gt;oracle.com&gt; --D -- 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> Darrick J. Wong 2013-06-18T16:55:54 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39216 <pre>Some of the functions which modify the jbd2 superblock were not updating the checksum before calling jbd2_write_superblock(). Move the call to jbd2_superblock_csum_set() to jbd2_write_superblock(), so that the checksum is calculated consistently. Signed-off-by: "Theodore Ts'o" &lt;tytso&lt; at &gt;mit.edu&gt; Cc: Darrick J. Wong &lt;darrick.wong&lt; at &gt;oracle.com&gt; Cc: stable&lt; at &gt;vger.kernel.org --- fs/jbd2/journal.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c index 4c8b8d4..28bcfa1 100644 --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c &lt; at &gt;&lt; at &gt; -1335,6 +1335,7 &lt; at &gt;&lt; at &gt; static int journal_reset(journal_t *journal) static void jbd2_write_superblock(journal_t *journal, int write_op) { struct buffer_head *bh = journal-&gt;j_sb_buffer; +journal_superblock_t *sb = journal-&gt;j_superblock; int ret; trace_jbd2_write_superblock(journal, write_op); &lt; at &gt;&lt; at &gt; -1356,6 +1357,7 &lt; at &gt;&lt; at &gt; static void jbd2_write_superblock(journal_t *journal, int write_op) clear_buffer_write_io_error(bh); set_buffer_up</pre> Theodore Ts'o 2013-06-18T15:54:02 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39215 <pre> Applied, thanks. - Ted -- 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> Theodore Ts'o 2013-06-18T15:40:53 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39214 <pre> Applied, thanks. - Ted -- 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> Theodore Ts'o 2013-06-18T15:24:46 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39213 <pre> Applied, thanks. - Ted -- 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> Theodore Ts'o 2013-06-18T15:21:01 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39212 <pre> Applied, thanks. - Ted -- 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> Theodore Ts'o 2013-06-18T15:14:38 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39211 <pre> Thanks, applied. - Ted -- 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> Theodore Ts'o 2013-06-18T15:08:22 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39210 <pre> Hi Wei, Thanks for pointing this out! I've folded this patch into the commit "ext4: avoid unnecessarily writing back dirty pages before hole punching". - Ted -- 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> Theodore Ts'o 2013-06-18T15:05:28 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39208 <pre>From: Wei Yongjun &lt;yongjun_wei&lt; at &gt;trendmicro.com.cn&gt; Add the missing unlock before return from function ext4_punch_hole() in the error handling case. Introduced by commit 1cdec9ca46c2c2a7ce452659f43dac64ad5fbc85. (ext4: Avoid unnecessarily writing back dirty pages before hole punching) Signed-off-by: Wei Yongjun &lt;yongjun_wei&lt; at &gt;trendmicro.com.cn&gt; --- fs/ext4/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 2644679..06136b5 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c &lt; at &gt;&lt; at &gt; -3538,7 +3538,7 &lt; at &gt;&lt; at &gt; int ext4_punch_hole(struct file *file, loff_t offset, loff_t length) if (ext4_should_order_data(inode)) { ret = ext4_begin_ordered_punch_hole(inode, offset, length); if (ret) -return ret; +goto out_mutex; } /* Now release the pages and zero block aligned part of pages*/ -- 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.kern</pre> Wei Yongjun 2013-06-18T03:40:34 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39207 <pre> generic/300. When I try to test my patch, I know that there has a report that invalidate page range patch set causes a regression, and I am not sure whether invalidate page range patch set causes it or not. So I decide to generate my patch against ext4/master. So, don't worry. :-) BTW, I will run xfstests this week. If I meet any regression, I will let you know. Thanks for pointing it out. - Zheng -- 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> Zheng Liu 2013-06-18T03:49:31 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39203 <pre>https://bugzilla.kernel.org/show_bug.cgi?id=59801 yyl810 &lt;yang.yulin&lt; at &gt;zte.com.cn&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from yyl810 &lt;yang.yulin&lt; at &gt;zte.com.cn&gt; 2013-06-18 01:14:51 --- I totally understand you and appreciate your suggestion. Actually yesterday I tried compiling 1.42.7 on my system, although it's succeeded, but unfortunately there is crash, anyway I found a way to try. Thanks again. </pre> bugzilla-daemon< at >bugzilla.kernel.org 2013-06-18T01:14:52 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39202 <pre> </pre> Mrs Anna Victoria 2013-06-14T12:04:33 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39201 <pre> Loan Syndicacion Am AFG Guaranty Trust Bank, zu strukturieren wir Kreditlinien treffen Sie unsere Kunden spezifischen geschäftlichen Anforderungen und einen deutlichen Mehrwert für unsere Kunden Unternehmen. eine Division der AFG Finance und Private Bank plc. Wenn Sie erwägen, eine große Akquisition oder ein Großprojekt sind, können Sie brauchen eine erhebliche Menge an Kredit. AFG Guaranty Trust Bank setzen können zusammen das Syndikat, das die gesamte Kredit schnürt für Sie. Als Bank mit internationaler Reichweite, sind wir gekommen, um Darlehen zu identifizieren Syndizierungen als Teil unseres Kerngeschäfts und durch spitzte diese Zeile aggressiv sind wir an einem Punkt, wo wir kommen, um als erkannt haben Hauptakteur in diesem Bereich. öffnen Sie ein Girokonto heute mit einem Minimum Bankguthaben von 500 £ und Getup zu £ 10.000 als Darlehen und auch den Hauch einer Chance und gewann die Sterne Preis von £ 500.000 in die sparen und gewinnen promo in may.aply jetzt. mit dem Folowin</pre> AFG GTBANK LOAN 2013-06-17T19:28:00 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39198 <pre>The while loop in mpage_map_and_submit_extent() is pointless; this function is only called if mpd.map.m_len is non-zero, and at the end of the while loop, mpage_map_and_submit_buffers sets mpd.map.m_len to be zero on success. (And on a failure, we return out of the while loop anyway.) Hence, the body of the while loop is guaranteed to execute once and exactly once. This also fixes a gcc warning complaining that err might be left uninitialized. Signed-off-by: "Theodore Ts'o" &lt;tytso&lt; at &gt;mit.edu&gt; Cc: Jan Kara &lt;jack&lt; at &gt;suse.cz&gt; --- fs/ext4/inode.c | 66 ++++++++++++++++++++++++++++----------------------------- 1 file changed, 32 insertions(+), 34 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 2644679..0e61543 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c &lt; at &gt;&lt; at &gt; -2157,44 +2157,42 &lt; at &gt;&lt; at &gt; static int mpage_map_and_submit_extent(handle_t *handle, mpd-&gt;io_submit.io_end-&gt;offset = ((loff_t)map-&gt;m_lblk) &lt;&lt; inode-&gt;i_blkbits; -while (map-&gt;m_len) { -err = mpage_map_one_extent(handle, mpd); -if (</pre> Theodore Ts'o 2013-06-17T13:58:07 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39197 <pre>The function mpage_released_unused_page() must only be called once; otherwise the kernel will BUG() when the second call to mpage_released_unused_page() tries to unlock the pages which had been unlocked by the first call. Also restructure the error handling so that we only give up on writing the dirty pages in the case of ENOSPC where retrying the allocation won't help. Otherwise, a transient failure, such as a kmalloc() failure in calling ext4_map_blocks() might cause us to give up on those pages, leading to a scary message in /var/log/messages plus data loss. Signed-off-by: "Theodore Ts'o" &lt;tytso&lt; at &gt;mit.edu&gt; Cc: Jan Kara &lt;jack&lt; at &gt;suse.cz&gt; --- fs/ext4/inode.c | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 0e61543..a183437 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c &lt; at &gt;&lt; at &gt; -2148,7 +2148,8 &lt; at &gt;&lt; at &gt; static int mpage_map_one_extent(handle_t *handle, struct mpage_da_data *mpd) * guaranteed). After mapping we </pre> Theodore Ts'o 2013-06-17T13:58:08 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39194 <pre> Applied, thanks. BTW, your patch was corrupted by your Mail User Agent. (It was sent in UTF-8 and with strange character set conversions.) - Ted -- 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> Theodore Ts'o 2013-06-17T12:57:30 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39193 <pre> Ok so it seem like the problems you're seeing here after the revert might be cause wrong revert. Simply applying patches #1 through #14 on top of the c7788792a5e7b0d5d7f96d0766b4cb6112d47d75 (Linux 3.10-rc2 - that seem to be what is ext4 branch based on?) does not yield any errors without journal. FSTYP -- ext4 PLATFORM -- Linux/x86_64 rhel6_vm1 3.10.0-rc2-debug+ MKFS_OPTIONS -- -q -F -b4096 -O ^has_journal /dev/sdb MOUNT_OPTIONS -- -o acl,user_xattr /dev/sdb /mnt/test1 generic/075 10s ... 10s generic/091 21s ... 18s generic/112 10s generic/127 286s ... 248s generic/231 206s ... 77s generic/255 1s ... 1s generic/263 16s ... 11s generic/269 29s ... 30s generic/270 32s ... 32s generic/300 8s ... 7s shared/218 4s shared/298 33s ... 21s Ran: generic/075 generic/091 generic/112 generic/127 generic/231 generic/255 generic/263 generic/269 generic/270 generic/300 shared/218 shared/298 Passed all 12 tests If required I will do the revert myself to make sure that nothing breaks. However I</pre> Lukáš Czerner 2013-06-17T12:30:28 http://permalink.gmane.org/gmane.comp.file-systems.ext4/39192 <pre> Ok, I though that there is something weird because patches #1-#14 should not cause anything like that and from my testing (see my previous mail) it really seems it does not cause it, at least not directly. As mentioned in previous email test generic/300 runs without any problems (even in the loop) without journal with patches #1 through #14 applied on 3.10-rc2 (c7788792a5e7b0d5d7f96d0766b4cb6112d47d75). This is on kvm with 24 cpu's, 8GB of RAM (I suppose you're not using 2MB of ram in your setup, but rather 2GB :) and server drives with linear lvm on top of it. -Lukas &gt; </pre> Lukáš Czerner 2013-06-17T12:46:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.file-systems.ext4