[lkml]   [2013]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: torrent hash failures since 3.9.0-rc1
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


 \ /
  Last update: 2013-03-12 00:21    [W:0.130 / U:3.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site