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/38843 <pre>Hi together, If you use the reserved field for this, users don't need to reformat their disks and "only" need to use a new kernel, right? That sounds really good to me. If there is a normal recording the PVR starts some minutes (I think 2-3) before the recording starts. If an user starts the PVR, timeshift (it's a recording) might start around 30-40 seconds after mounting the disk. But if it's problematic I can let it start later. Yes, adding a line to rc.local is easy. Building a new kernel is also no problem, if the patch is compatible with the current used kernel versions (3.8.7 and also good would be 3.3.8 ). The PVR uses a good software management system (something like apt) and the users can update their software including kernel every day. Reformating is a problem, but if it's not preventable, users can choose between workaround and reformat. Best regards, Frank -- 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</pre> frankcmoeller< at >arcor.de 2013-05-20T20:54:22 http://comments.gmane.org/gmane.comp.file-systems.ext4/38841 <pre>In fs/ext4/xattr.c file, the function ex4_xattr_set_entry(), the size of xattr space we use the pad to count it .In line 675: size_t size = EXT4_XATTR_SIZE(i-&gt;value_len); We use the EXT_XATTR_SIZE to count the value_len,then get the xattr's used space. But in fs/ext4/inline.c file,we just use the actual size to count the inlinedata free size,in function get_max_inline_xattr_value_size() ,line 75,such as: free += le32_to_cpu(entry-&gt;e_value_size); This may bring in a bug about count the inlinedata free space. The bug reproduction way: 1. in the subarea with inline_data feature touch test 2. use echo to add to write the test file 129 bytes 3. use the "stat" to get the test file's status stat test the result is: .....size:129 block:0 ..... 4.use echo to add one byte in the test file echo -n "0"&gt;&gt;test 5.use the "stat" to get the test file's status stat test the result is: .....size:130 block:8 ..... It is incorrect.In inline_data feature,only when the size is bigger then 132,it will </pre> boxi liu 2013-05-20T14:50:57 http://comments.gmane.org/gmane.comp.file-systems.ext4/38837 <pre>Primarily signed vs unsigned and const warnings. Signed-off-by: "Theodore Ts'o" &lt;tytso&lt; at &gt;mit.edu&gt; --- debian/e2fslibs.symbols | 1 - lib/ext2fs/bitops.c | 2 +- lib/ext2fs/bitops.h | 19 ++++++++----------- lib/ext2fs/blkmap64_rb.c | 48 ++++++++++++++++++++++++++++------------------- lib/ext2fs/block.c | 4 ++-- lib/ext2fs/crc32c.c | 8 ++++---- lib/ext2fs/gen_bitmap64.c | 2 +- lib/ext2fs/mmp.c | 3 ++- lib/ext2fs/rbtree.c | 4 ++-- lib/ext2fs/rbtree.h | 4 ++-- lib/ext2fs/rw_bitmaps.c | 3 ++- lib/ext2fs/symlink.c | 2 +- 12 files changed, 54 insertions(+), 46 deletions(-) diff --git a/debian/e2fslibs.symbols b/debian/e2fslibs.symbols index b8eea52..5784a25 100644 --- a/debian/e2fslibs.symbols +++ b/debian/e2fslibs.symbols &lt; at &gt;&lt; at &gt; -352,7 +352,6 &lt; at &gt;&lt; at &gt; libext2fs.so.2 e2fslibs #MINVER# ext2fs_open_file&lt; at &gt;Base 1.42 ext2fs_open_inode_scan&lt; at &gt;Base 1.37 ext2fs_parse_version_string&lt; at &gt;Base 1.37 - ext2fs_print_bmap_statistics&lt; at &gt;Base 1.42.1 ext2fs_process_dir</pre> Theodore Ts'o 2013-05-20T13:58:57 http://comments.gmane.org/gmane.comp.file-systems.ext4/38836 <pre>Signed-off-by: "Theodore Ts'o" &lt;tytso&lt; at &gt;mit.edu&gt; --- lib/ext2fs/blkmap64_rb.c | 4 +++- lib/ext2fs/crc32c.c | 6 +++--- lib/ext2fs/csum.c | 22 ++++++++++++---------- lib/ext2fs/ext2fs.h | 4 +++- 4 files changed, 21 insertions(+), 15 deletions(-) diff --git a/lib/ext2fs/blkmap64_rb.c b/lib/ext2fs/blkmap64_rb.c index 9c1abc5..d6442fc 100644 --- a/lib/ext2fs/blkmap64_rb.c +++ b/lib/ext2fs/blkmap64_rb.c &lt; at &gt;&lt; at &gt; -862,7 +862,9 &lt; at &gt;&lt; at &gt; static void rb_print_stats(ext2fs_generic_bitmap bitmap) eff); } #else -static void rb_print_stats(ext2fs_generic_bitmap bitmap){} +static void rb_print_stats(ext2fs_generic_bitmap bitmap EXT2FS_ATTR((unused))) +{ +} #endif struct ext2_bitmap_ops ext2fs_blkmap64_rbtree = { diff --git a/lib/ext2fs/crc32c.c b/lib/ext2fs/crc32c.c index 4e72eda..624ad77 100644 --- a/lib/ext2fs/crc32c.c +++ b/lib/ext2fs/crc32c.c &lt; at &gt;&lt; at &gt; -125,7 +125,7 &lt; at &gt;&lt; at &gt; crc32_body(uint32_t crc, unsigned char const *buf, size_t len, len = rem_len; /* And the last few bytes */ if (len) { -uint8_t *p </pre> Theodore Ts'o 2013-05-20T13:59:01 http://comments.gmane.org/gmane.comp.file-systems.ext4/38823 <pre>The following BUG happened today at a stable Gentoo Linux 32bit system with stable kernel 3.9.3: 2013-05-19T23:28:34.195+02:00 n22 kernel: ------------[ cut here ]------------ 2013-05-19T23:28:34.195+02:00 n22 kernel: kernel BUG at fs/ext4/inode.c:1590! 2013-05-19T23:28:34.195+02:00 n22 kernel: invalid opcode: 0000 [#1] SMP 2013-05-19T23:28:34.195+02:00 n22 kernel: Modules linked in: loop rc_dib0700_rc5 dvb_usb_dib0700 dib3000mc dib8000 dvb_usb dib0070 dib7000m dib7000p dvb_core dibx000_common dib0090 rc_core nfsd auth_rpcgss ipt_MASQUERADE xt_owner xt_multiport ipt_REJECT xt_tcpudp xt_recent xt_conntrack xt_limit xt_LOG iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables af_packet pppoe pppox ppp_generic slhc bridge stp llc tun coretemp kvm_intel kvm fbcon bitblit usblp softcursor font psmouse acpi_cpufreq i915 uvcvideo sdhci_pci cfbfillrect sdhci videobuf2_vmalloc cfbimgblt videobuf2_memops i2c_algo_bit mmc_core videobuf2_core cfbcopyarea intel_a</pre> Toralf Förster 2013-05-19T22:25:17 http://comments.gmane.org/gmane.comp.file-systems.ext4/38822 <pre>Hi Ted, Thanks for confirming that the workaround fixes the problem! From my point (end user) I would prefer a builtin solution. I'm also a programmer and I can therefore understand why you don't want to change anything. It's a little bit surprising for me, that only few people seems to have this problem. But I believe that many live with it and don't know that the slow boot or write is caused by ext4 (and many end user have small ext4 partitions and servers are running 24/7 without remounting fs...). Only few applications rely on a constant write throughput. Well, SSDs are really cool, but for a PVR a hdd is still a good choice: Cheap, big, more reliable (hopefully), quick enough and has no problems writing several GB data per day. Regards, Frank -- 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> frankcmoeller< at >arcor.de 2013-05-19T19:36:02 http://comments.gmane.org/gmane.comp.file-systems.ext4/38813 <pre>Hi Andrei, thanks for your quick answer! Perhaps you understood me wrong. The general write performance is quite good. We can record more than 4 HD channels at the same time without problems. Except the problems with the first write after mount. And there are also some users which have problems 1-2 times during a recording. I think the ext4 group initialization is the main problem, because it takes so long (as written before: around 1300 groups per second). Why don't you store the gathered informations on disk when a umount takes place? With fallocate the group initialization is partly made before first write. This helps, but it's no solution, because the finally file size is unknown. So I cannot preallocate space for the complete file. And after the preallocated space is consumed the same problem with the initialization arises until all groups are initialized. I also made some tests with O_DIRECT (my first tests ever). Perhaps I did something wrong, but it isn't very fast. And you have to take care about</pre> frankcmoeller< at >arcor.de 2013-05-18T10:50:02 http://comments.gmane.org/gmane.comp.file-systems.ext4/38804 <pre>Hi, we're using ext4 on satellite boxes (e.g. XTrend et9200) with mounted harddisks. The receiver uses linux with kernel version 3.8.7. Some users (like me) have problems with the first recording right after boot. Most of them have big partitions(1-2TB) and high disk usage (over 50%). The application signals in this case a buffer overflow (the buffer is 4 MB big). We found out, that one of the first writes after boot or remount is very slow. I have debugged it. The testcase was a umount then mount and then a write of 64MB data to the disk: The problem is the initialization of the buffer cache which takes very long(ext4_mb_init_group in ext4_mb_good_group procedure). In my case it loads around 1300 groups per second (with the patch which avoids loading full groups). My disk is at the beginning quite full, so it needs to read around 8200 groups to find a "good" one. This takes over 6 seconds. Here is the output: May 10 02:06:15 et9x00 user.info kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode</pre> frankcmoeller< at >arcor.de 2013-05-17T16:51:23 http://comments.gmane.org/gmane.comp.file-systems.ext4/38775 <pre>If filesystem was aborted after inode's write back complete but before it's metadata was updated we may return success due to (sb-&gt;s_flags &amp; MS_RDONLY) which is incorrect and result in data loss. In order to handle fs abort correctly we have to check fs state once we discover that it is in MS_RDONLY state Test case: http://patchwork.ozlabs.org/patch/244297/ Signed-off-by: Dmitry Monakhov &lt;dmonakhov&lt; at &gt;openvz.org&gt; --- fs/ext4/fsync.c | 8 ++++++-- fs/ext4/super.c | 13 ++++++++++++- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/fs/ext4/fsync.c b/fs/ext4/fsync.c index e0ba8a4..d7df2f1 100644 --- a/fs/ext4/fsync.c +++ b/fs/ext4/fsync.c &lt; at &gt;&lt; at &gt; -129,9 +129,13 &lt; at &gt;&lt; at &gt; int ext4_sync_file(struct file *file, loff_t start, loff_t end, int datasync) return ret; mutex_lock(&amp;inode-&gt;i_mutex); -if (inode-&gt;i_sb-&gt;s_flags &amp; MS_RDONLY) +if (inode-&gt;i_sb-&gt;s_flags &amp; MS_RDONLY) { +/* Make shure that we read updated s_mount_flags value */ +smp_rmb(); +if (EXT4_SB(inode-&gt;i_sb)-&gt;s_mount_flags &amp; EXT4_MF_FS</pre> Dmitry Monakhov 2013-05-16T12:28:07 http://comments.gmane.org/gmane.comp.file-systems.ext4/38774 <pre>Parallels team have old good tool called hwflush-check which is server/client application for testing data integrity under system/disk failure conditions. Usually we run hwflush-check on two different hosts and use PMU to trigger real power failure of the client as a whole unit. This tests may be used for SSD checking (some of them are known to have probelms with hwflush). I hope it will be good to share it with community. This tests simulate just one disk failure while client system should survive this failure. This test extend idea of shared/305. 1) Run hwflush-check server and client on same host as usual 2) Simulare disk failure via blkdev failt injection API aka 'make-it-fail' 3) Umount failed device 4) Makes disk operatable again 5) Mount filesystem 3) Check data integrity Surprasingly this 'single disk failure test' uncover data loss on reccent kernel (3.10-rc1) for EXT4 and XFS. Signed-off-by: Dmitry Monakhov &lt;dmonakhov&lt; at &gt;openvz.org&gt; --- aclocal.m4 | 1 + configure.ac | 2 + </pre> Dmitry Monakhov 2013-05-16T12:07:32 http://comments.gmane.org/gmane.comp.file-systems.ext4/38764 <pre> Hello. I saw some commit messages about excessive stall times in ext4. The same problem was reproduced in my board. Actually, i'm not sure that is the same problem. But the calltrace message is very similar with commit id: f783f091. My board configuration as follow. Linux: 2.6.32.60 CPU: 8CPU Disk: SSD File system: ext4 I know my kernel version is so old. I just want to know why this problem is happened. Because of my kernel version is old? or Because of disk ?,, If anyone knows about this problem, Could you help me? As i said, the calltrace message is very similar with commit id: f783f091 as below. Because i enabled hungtask detection and set the hungtask timeout to 120 seconds. the calltrace messages were printed by this. [ 262.455615] INFO: task swm:1692 blocked for more than 120 seconds. [ 262.461715] Stack : 0000000000000000 ffffffff8011f684 0000000000000000 a8000001f8b33960 [ 262.469438] a8000001f7f2ce38 00000000ffffb6a9 0000000000000005 ffffffff80efa270 [ </pre> EUNBONG SONG 2013-05-15T07:15:01 http://comments.gmane.org/gmane.comp.file-systems.ext4/38730 <pre> The following changes since commit 0d606e2c9fccdd4e67febf1e2da500e1bfe9e045: ext4: fix type-widening bug in inode table readahead code (2013-04-23 08:59:35 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus_stable for you to fetch changes up to e2555fde4159467fb579e6ae3c0a8fc33015d0f5: jbd,jbd2: fix oops in jbd2_journal_put_journal_head() (2013-05-13 09:45:01 -0400) ---------------------------------------------------------------- Fixed regressions (two stability regressions and a performance regression) introduced during the 3.10-rc1 merge window. Also included is a bug fix relating to allocating blocks after resizing an ext3 file system when using the ext4 file system driver. ---------------------------------------------------------------- Jan Kara (1): jbd,jbd2: fix oops in jbd2_journal_put_journal_head() Lachlan McIlroy (1): ext4: limit group search loop for non-extent files Theodore Ts'o (1): e</pre> Theodore Ts'o 2013-05-14T16:09:02 http://comments.gmane.org/gmane.comp.file-systems.ext4/38724 <pre>Hi, Is it possible to "scrub" (check/verify) (the new-) checksums in ext4? Also: is it planned to add an option to add checksums to the data as well? Folkert van Heusden </pre> folkert 2013-05-14T09:14:08 http://comments.gmane.org/gmane.comp.file-systems.ext4/38723 <pre>For hole punching, currently ext4 will synchronously write back the dirty pages fit into the hole, since the data on the disk responding to those pages are to be deleted, it is benefical to directly release those pages, no matter they are dirty or not, except the ordered case. Signed-off-by: Li Wang &lt;liwang&lt; at &gt;ubuntukylin.com&gt; Signed-off-by: Yunchuan Wen &lt;yunchuanwen&lt; at &gt;ubuntukylin.com&gt; Reviewed-by: Theodore Ts'o &lt;tytso&lt; at &gt;mit.edu&gt; Reviewed-by: Dmitry Monakhov &lt;dmonakhov&lt; at &gt;openvz.org&gt; --- fs/ext4/inode.c | 21 ++++++++++------- fs/jbd2/transaction.c | 62 +++++++++++++++++++++++++++++++------------------ include/linux/jbd2.h | 2 ++ 3 files changed, 55 insertions(+), 30 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 0723774..3e00360 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c &lt; at &gt;&lt; at &gt; -3578,6 +3578,16 &lt; at &gt;&lt; at &gt; int ext4_can_truncate(struct inode *inode) return 0; } +static inline int ext4_begin_ordered_fallocate(struct inode *inode, + loff_t start, loff_t length) +{ +if (!E</pre> Li Wang 2013-05-14T07:44:54 http://comments.gmane.org/gmane.comp.file-systems.ext4/38708 <pre>Hi, I created this very short series that adds the itree flags to e2fsprogs mke2fs and tune2fs in case someone would like to try the itree patches. A RFC patches were posted to linux-ext4 with this feature implemented, however, it is still *highly* experimental. I am still working on it. Changes from v1 =============== * The feature + inode flag patches merged together * Added more detailed commit messages -Radek Radek Pazdera (2): libext2fs: Adding itree feature and inode flags mke2fs, tune2fs: Adding support for the itree flag lib/e2p/feature.c | 2 ++ lib/e2p/pf.c | 1 + lib/ext2fs/ext2_fs.h | 2 ++ misc/mke2fs.c | 3 ++- misc/tune2fs.c | 6 ++++-- 5 files changed, 11 insertions(+), 3 deletions(-) </pre> Radek Pazdera 2013-05-13T15:43:48 http://comments.gmane.org/gmane.comp.file-systems.ext4/38697 <pre>Hello everyone, I am a university student from Brno /CZE/. I'm trying to optimise the readdir/stat scenario in ext4 as the final project to school. I posted some test results I got few months ago [1]. And following that, I tried to implement an additional tree for ext4's directory index that would be sorted by inode numbers. The tree is used by ext4_readdir() which should lead to substantial increase of performance of operations that manipulate a whole directory at once. The performance increase should be visible especially with large directories or in case of low memory or cache pressure. This patch series is what I've got so far. I must say, I originally thought it would be *much* simpler :). TLDR ==== The series contains the implementation of the new tree and several rather small changes to the original directory index. I also added a new implementation of ext4_readdir() that uses this new tree instead of the original one. It applies on 3.10-rc1, it should be basically working, however, it is highl</pre> Radek Pazdera 2013-05-13T15:42:01 http://comments.gmane.org/gmane.comp.file-systems.ext4/38684 <pre>Commit ae4647fb (jbd2: reduce journal_head size.) introduced a regression where we occasionally hit panic in jbd2_journal_put_journal_head() because of wrong b_jcount. The bug is caused by gcc making 64-bit access to 32-bit bitfield and thus clobbering b_jcount. At least for now, those 8 bytes saved in struct journal_head are not worth the trouble with gcc bitfield handling so revert that part of the patch. Reported-by: EUNBONG SONG &lt;eunb.song&lt; at &gt;samsung.com&gt; Signed-off-by: Jan Kara &lt;jack&lt; at &gt;suse.cz&gt; --- include/linux/journal-head.h | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) Ted, this should fix the regression reported by EUNBONG SONG. Please apply. diff --git a/include/linux/journal-head.h b/include/linux/journal-head.h index 13a3da2..3594c74 100644 --- a/include/linux/journal-head.h +++ b/include/linux/journal-head.h &lt; at &gt;&lt; at &gt; -30,15 +30,19 &lt; at &gt;&lt; at &gt; struct journal_head { /* * Journalling list for this buffer [jbd_lock_bh_state()] + * NOTE: We *cannot* combine this with b_modified into a bitf</pre> Jan Kara 2013-05-13T13:31:56 http://comments.gmane.org/gmane.comp.file-systems.ext4/38670 <pre>Hi, I'm curious if anyone ever tried fua-only jbd? If done with fua's, there will be no cache flushes at all, thus no occasional spikes. NCQ fua journalling is potentially more efficient than cache flush. I know, stale data will be unavoidable (however unlikely) in fua-based implementation. It is a compromise between ordered,nobarrier (fs corruption is likely to happen upon power loss) and ordered,barrier (no fs corruption). Any advise on what kind of workload to test? What about having single journal per device as opposed to partition/fs? What I've found of quick look at jbd2 code, it doesn't seem to be a problem to set up single journal for several filesystems on the same device. This will give an advantage of single commit per commit interval as opposed to several commits per likely to be same interval. </pre> Sidorov, Andrei 2013-05-13T07:54:48 http://comments.gmane.org/gmane.comp.file-systems.ext4/38668 <pre>Hi, I ran into the deaclock with xfs_test 269 on linux-3.9.0. It seems happen between jbd2_log_wait_commit, sleep_on_buffer and writeback_indoes (Please see ps log below). Once it occurs we can't touch FS anymore. In my case 300 - 1000 trials to occur. Is this known issue? The following kernels seems to have same problem: - linux-3.5-rc5 - linux-3.8.5 - linux-3.9-rc7 And now I'm trying it on linux-3.10-rc1. # ./check generic/269 FSTYP -- ext4 PLATFORM -- Linux/x86_64 mcds1 3.9.0 MKFS_OPTIONS -- /dev/sda12 MOUNT_OPTIONS -- -o acl,user_xattr /dev/sda12 /mnt/mp2 # ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:16,comm PID TID CLS RTPRIO NI PRI PSR %CPU STAT WCHAN COMMAND 1 1 TS - 0 19 0 0.0 Ss poll_schedule_ti init 2 2 TS - 0 19 0 0.0 S kthreadd kthreadd 3 3 TS - 0 19 0 0.0 S smpboot_thread_f ksoftirqd/0 ... 2391 2391 TS - 0 19 2 0.1 D jbd2_log_wait_co flush-8:0 ... 22647 22647</pre> Akira Fujita 2013-05-13T06:49:24 http://comments.gmane.org/gmane.comp.file-systems.ext4/38653 <pre>Greetings, I am a Civil Lawyer in the United Kingdom. I have a Client that has Interest in investing in Your country. Can You be of assistance? I shall give you details when you reply Wayne -- 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> Mr. Wayne Scott 2013-05-06T19:18:18 http://comments.gmane.org/gmane.comp.file-systems.ext4/38650 <pre>Greetings, I am a Civil Lawyer in the United Kingdom. I have a Client that has Interest in investing in Your country. Can You be of assistance? I shall give you details when you reply Wayne -- 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> Mr. Wayne Scott 2013-05-03T18:14:24 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.file-systems.ext4