Cryptooctoploid wrote: > On Mon, Nov 3, 2008 at 2:40 PM, Theodore Tso <tytso@xxxxxxx> wrote: >> On Mon, Nov 03, 2008 at 12:42:11PM +0000, Roc Valles wrote: >>> Some person already reported this. I'm having the same problem. >>> http://marc.info/?l=linux-ext4&m=122557056518246&w=2 >>> >>> rtorrent is a bittorrent client that makes heavy use of mmap instead >>> of read/write to avoid needless duplication of data. It has exposed >>> other bugs in the past (mmap bug in 2.6.19). >>> http://libtorrent.rakshasa.no >>> Downloading a big torrent (>2GB) with rtorrent triggers it more times >>> than not. The bigger the torrent, the higher the likeliness of >>> failure. When the torrent is finished, if a hash check is forced by >>> pressing control-r on the torrent, some blocks will fail. >> Can both of you send the output of "dumpe2fs -h /dev/<disk device>" of >> the filesystem in question? The thing which I'm most interested in is >> whether the extents feature was enabled or not. (i.e., was this a >> freshly made ext4 filesystem, or a ext3 filesystem mounted under ext4, >> and with which features eanbled?) >> > > I tested this further and it turned out that this bug is not extents > related. I get the same hash failures on a partition formatted with: > -O "^extent". Thanks, that's good information. > Besides the torrent failures, ext4 also managed to corrupt two > dspam sqlite3 databases on my system. (After the corruption I > get the following error: > *** glibc detected *** dspam: free(): invalid pointer: 0x0000000001e71c58 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7fcd1f941af6] > /lib/libc.so.6(cfree+0xbd)[0x7fcd1f942f3d] > /usr/lib64/dspam/libsqlite3_drv.so(_ds_setall_spamrecords+0x395)[0x7fcd1ea03075] > /usr/lib/libdspam.so.7(_ds_operate+0x400)[0x7fcd1fc3c710] > /usr/lib/libdspam.so.7(dspam_process+0x1d9)[0x7fcd1fc3cf49] > dspam(process_message+0xb49)[0x408579] > dspam(process_users+0x57d)[0x40902d] > dspam(main+0x2c2)[0x409832] > /lib/libc.so.6(__libc_start_main+0xfd)[0x7fcd1f8e848d] > dspam[0x402f79 > and the only solution is to restore the database from ext3 backup) I think this would more likely indicate a userspace bug, though, not something related to ext4. -Eric > My conclusion is that ext4 is not yet ready for prime time. > I moved all my data back to ext3. > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
