mount.ntfs causes 100% CPU (iowait)

[TJ]

Binary package hint: ntfs-3g

apt-cache policy ntfs-3g
ntfs-3g:
  Installed: 1:2009.1.1-0ubuntu1
  Candidate: 1:2009.1.1-0ubuntu1
  Version table:
 *** 1:2009.1.1-0ubuntu1 0
        500 http://gb.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

In /dev/sda1 is a NTFS Sony Windows Recovery file-system. It is set to auto-mount via /etc/fstab to /media/WindowsRecovery.

I was copying an NTFS partition image using dd from an external USB hard-drive to /dev/sda2 (after replacing the laptop's internal hard-disk).

I'm not sure when it began but I noticed the CPU monitor shoot up to 100% and it has remained there for more than 10 minutes. The CPUs are in I/O wait and I noticed in the process list mount.ntfs has been hanging around.

Despite the I/O wait there is little to no hard-disk activity judging by the LED indicator.

I tried to kill the process using "sudo killall mount.ntfs" but after entering the password the terminal froze before carrying out the command. I tried using sudo with another command from another terminal shell and that has also froze after the password was provided.

ps -eFlL | grep mount.ntfs
1 S root 4623 1 4623 0 1 80 0 - 4083 fuse_d 928 0 01:37 ? 00:00:01 /sbin/mount.ntfs /dev/sda1 /media/WindowsRecovery -o rw
4 S root 7628 7371 7628 0 1 80 0 - 8953 unix_w 1436 0 02:11 pts/2 00:00:00 sudo killall mount.ntfs
0 S tj 7771 7694 7771 0 1 80 0 - 1873 pipe_w 1000 0 02:24 pts/3 00:00:00 grep mount.ntfs

I tried switching to VT1. It accepted my user password to log-in and displayed the motd but then froze before any shell prompt can be displayed.

[Szabolcs Szakacsits (szaka)]

It's not clear what you copied from where to where and how.

Anyway it looks to be a hardware problem. Check your RAM and disks for bad sectors, e.g. by the utility badblocks.

[TJ (tj)]

Copying is clear enough:

"I was copying an NTFS partition image using dd from an external USB hard-drive to /dev/sda2 (after replacing the laptop's internal hard-disk)."

E.g. dd if=/media/mobile120/vista.img of=/dev/sda2

The file being copied was 29GB.

I mentioned it simply because it might be related, but the actual issue was mount.ntfs processing /dev/sda1 (which contains a Windows Recovery NTFS file-system).

There is/was no hardware problem.

Somehow mount.ntfs and the fuse daemon got stuck in a deadlock.

I wish I knew how to reproduce it but it isn't clear what triggered the mount in the first place. I 'assume' it was some part of the nautilus auto-mount triggering but as the drive is internal that doesn't quite make sense.

Possibly the large ongoing data transfer to /dev/sda2 caused a problem/delay that fuse daemon couldn't handle when it was asked to mount /dev/sda1, and it got stuck spinning on I/O.

[Szabolcs Szakacsits (szaka)]

It's impossible to see what NTFS-3G has to do with the problem.

Yes, the /dev/sda1 NTFS partition is mounted at /media/WindowsRecovery by NTFS-3G but you were reading from another file system mounted at /media/mobile120 and writing to partition /dev/sda2.

The IOWAIT is completely normal when one is copying data. If no disk activity than that's usually a hardware or kernel device driver problem, most typically USB problem when an external device is involved. Like it disconnected, auto-suspended, etc. Did you check your kernel logs?

mount.ntfs in the process list is completely normal when at least one partition is mounted.

Th FUSE daemon speculation doesn't stand either. The only FUSE daemon is mount.ntfs which can not deadlock itself, especially when it's not used for anything.

[TJ (tj)]

Thanks for the explanation, Szabolcs.

I can't remember the exact details now of course, but I do remember that the 'dd' copy from USB to /dev/sda2 had finished when I spotted the CPU monitor showing the I/O wait.

I hadn't spotted mount.ntfs in the process list previously, although admittedly I'd never been looking for it. I tend to be looking at top or "ps -ef | grep ..." output much of the time.

I'm wondering if what I saw was the results of the 'dd' copy failing because the USB device had an error. I didn't notice any dd error since I'd had that running in the background because it takes a while - I'd gone off to do others things.

From your explanation it looks like my linkage of the issue with mount.ntfs was a result of coincidence.

Since I can't reproduce it I'll mark the report invalid. Thanks for your input.

[Kevin (kpapst)]

I can tell you how to reproduce it easily: It has todo with the filesize.

Try to copy a file which is larger than 4.X GB and the CPU usage bumps up to > 90%.

I can safely reproduce it. Leech a file (lets say 5 GB) - CPU usage 90%. Stop it - CPU usage normal. Restart it CPU usage 90%.
Stop it and start smaller files - CPU usage normal.

Move the same large file to an ext3 drive - CPU usage normal.

Give it a try, I can safely reproduce this behavior for months now.

[Kevin (kpapst)]

Oh and I forgot to mention that the problem arises ONLY after the mentioned amount of somewhere around 4,4 GB were written. Before that point everything is fine. But as the file grows, the CPU usage suddenly jumps up.

[Gordon Fern (gordon-fern)]

I've experienced a very similar problem Ubuntu 9.10. copying a large file from ext4 filing system to USB ntfs drive (23GB). mount.ntfs consuming 85-95% + of CPU most of which is %user. iostat 6 100 shows writes at 83/sec or less. It will succeed eventually but will probably take best part of 24hours. The file is actually a VirtualBox export last night I tried exporting it directly to ntfs drive but 8 hours later it had only achieved 15% of the export, hence exporting it to the ext4 disk and now copying again.

[Ophir Setter (ophir-setter)]

Same problem here.

I have a 500GB USB external drive and wanted to keep it NTFS. I also wanted to copy my full home directory from one computer to the other. I created an ext4 loopback file on the NTFS and started coping. When I reached to VirtualBox image on my home directory it got stuck. Afterwards it always got stuck even when excluding the VirtualBox.

The NTFS loop continued even after I kill rsync.
Eventually I dropped the idea of having a ext4 loopback on NTFS (I also wanted to use it for backup).

O

[Ophir Setter (ophir-setter)]

PS: Home folder about 30GB, VirtualBox about 10GB. The whole process got stuck when the loopback file was about 13GB.

[Pako (elektrobank01)]

Same here on Maverick. In fact it uses 45-50% of CPU, xorg 15-25% and nautilus 15% in total 85-90%. I was copying files for 15 minutes, at one moment I thought that my laptop will melt from the heat. I really don't understand why this bug is marked as Invalid.