Bug 217253

Summary: KTorrent corrupts XFS filesystem
Product: [Applications] ktorrent Reporter: Dmitry Pisklov <dpisklov>
Component: generalAssignee: Joris Guisson <joris.guisson>
Status: RESOLVED UPSTREAM    
Severity: major    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Log from syslog

Description Dmitry Pisklov 2009-12-03 19:59:06 UTC
Version:           3.2.4 (using KDE 4.3.3)
OS:                Linux
Installed from:    Ubuntu Packages

KTorrent with torrents seeding/downloading from XFS mounts crashing and corrupting filesystems (i.e. XFS partitions) it uses in the moment crash event occured. Also this can cause (and can cause not) system hang.

First crash occured under Arch linux. After reboot I was able to repair my partitions with xfs_check/xfs_repair. smartctl reported no errors on HDDs I use. There're three HDDs in my system, corrupted partitions were located on 2 of 3 drives. Also, I've noticed that only partitions currently used by KTorrent (i.e. in the moment it crashes) are corrupted, and the list of corrupted partitions is different from failure to failure.

Again - smartctl shown no errors, I've run long SMART tests and no errors were reported - so this issue is not related to my HDDs.

Then - I've setup Kubuntu karmic - and got the same after several hours - system was hang, and log from syslog is attached.

I tried to use vuze/azureus and qBittorrent - and they both worked well without crashes. It means the issue is not in XFS or something else - issue is related to KTorrent and (possibly) to KTorrent's work with XFS.

And finally - I've already used KTorrent on my system several versions ago (I guess, a year ago or about), and had no problems.
Comment 1 Dmitry Pisklov 2009-12-03 19:59:50 UTC
Created attachment 38809 [details]
Log from syslog
Comment 2 Joris Guisson 2009-12-05 15:12:54 UTC
If an application can corrupt a filesystem when it is using that filesystem, the bug is in the filesystem.

Note that it seems to be fixed in linux kernel 2.6.32-rc:

http://oss.sgi.com/bugzilla/show_bug.cgi?id=852