On 2013.03.11 at 16:37 -0400, Theodore Ts'o wrote: > On Mon, Mar 11, 2013 at 09:13:34PM +0100, Markus Trippelsdorf wrote: > > On 2013.03.11 at 15:41 -0400, Dave Jones wrote: > > > Worked fine for me on two separate machines. Could it be a network problem > > > perhaps ? If something is mangling the packet before it hits the disk, > > > that would explain it. What NIC do you use ? > > I'm not a torrent expert, but I thought it did enough checksumming > such that if the packet got mangled, it would get noticd by the > torrent client before it writes the chunks to disk? Yes, I think that's the idea. > > > Or maybe you could isolate it to a filesystem problem using something > > > like fsx ? > > > > I've found fsx on your homepage, but I've no idea on how to use this > > tool. Any pointers? > > We actually run fsx in a number of different configruations as part of > our regression testing before we send Linus a pull request, and > haven't found any issues. So unless it's a hardware problem, it seems > unlikely to me that your running fsx would turn up anything. Yes, I let it run for a while anyway and it didn't report any failure. > Can you send a dumpefs -h of the file system in question, and what > mount options (if any) you are using? Thanks!! # dumpe2fs -h /dev/sda dumpe2fs 1.42.7 (21-Jan-2013) Filesystem volume name: <none> Last mounted on: /var Filesystem UUID: 202f2c93-c6c5-4d70-a63f-d770161138bd Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 91578368 Block count: 366284646 Reserved block count: 18314232 Free blocks: 185850075 Free inodes: 90003798 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 936 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Mon Nov 19 16:02:46 2012 Last mount time: Mon Mar 11 21:16:23 2013 Last write time: Mon Mar 11 21:16:23 2013 Mount count: 20 Maximum mount count: -1 Last checked: Mon Mar 4 13:32:55 2013 Check interval: 0 (<none>) Lifetime writes: 2891 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 60164803 Default directory hash: half_md4 Directory Hash Seed: e86f34a0-390a-49b6-87a9-3336d861ab81 Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 128M Journal length: 32768 Journal sequence: 0x00079bef Journal start: 1 noatime is the only mount option. > BTW, I'm currently running 3.9-rc2 with some additional fixes from the > ext4 dev branch, and I'm not able to reproduce the problem using > rtorrent on my laptop. How reliably is it reproducing for you? Are > you seeing the problem every time you try this? Yes, it's 100% reproducible for me. If I boot a 3.8 kernel the issue vanishes. -- Markus -- 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
