1

This just barely started occurring and I feel like this is not a bug but a configuration error (hopefully). I'm on 12.04, 64-bit and have been happily stable for many months. My RAID1 is years old and has also had no issues until recently. The disks are healthy. As of today, though, every time I try to copy files over to the RAID the journaling daemon goes bonkers and uses 99% of the disk IO, forcing my file transfer speed to pathetic amounts (usually 1 MB/s).

I've tried restarting to no effect (I haven't changed any settings anywhere to my knowledge. Attached is a screenshot of iotop demonstrating the usage:

iotop

When not copying it goes back down to 0 percent.

Here is my /etc/fstab:

# / was on /dev/sdh2 during installation
UUID=15bb606e-54af-4fa3-8341-12824a404dae /                       ext4    errors=remount-ro   0       1
# /home was on /dev/sdh3 during installation
UUID=9eed87ee-f9d5-47c7-91e5-b82696142f7e /home                   ext4    defaults            0       2
# swap was on /dev/sdh4 during installation
UUID=27f06259-705d-48ba-83d6-3e1837a87198 none                    swap    sw                  0       0
# Music RAID
UUID=d10e627b-6068-4734-9111-5e2f71dbbe4f /media/Music_Library    ext4    auto,user,sync      0       1

output of /proc/mdstat:

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md127 : active raid1 sdb1[1] sdh1[0]
  292968181 blocks super 1.2 [2/2] [UU]
unused devices: <none>

df -h:

/dev/md127p1    276G  112G  150G  43% /media/Music_Library

Please advise, and thank you :)

4
  • 1
    Do you really need the sync mount option?
    – gertvdijk
    Jan 3, 2013 at 2:50
  • No, not really. I forget my reasoning for putting it there but I had one a few years ago ;).
    – user6658
    Jan 3, 2013 at 4:09
  • 1
    Did it help removing this parameter? (then run sudo mount -o remount /media/Music_Library or reboot) Please also provide more information on the RAID status (e.g. cat /proc/mdstat) and the file system usage (df -h -P | grep Music_Library). If it's used to higher limits, say > 90% this can also cause severe performance degradation.
    – gertvdijk
    Jan 3, 2013 at 9:45
  • It appears that removing the 'sync' option fixed the issue for me. Thanks so much - if you'd like answer points, please put that as an answer and I'll accept it.
    – user6658
    Jan 3, 2013 at 15:34

1 Answer 1

0

The sync mount options makes writes to your disk to happen synchronously. This is a good thing if you have a reason for it. One reason for enabling this is to minimize the amount of data loss during power failures, as it will try to disable all kinds of caching features. This is useful if you're interested in the safest possible way to write data to your disk.

As you've stated, you don't have this particular requirement and you'd like to see a better performance instead. By removing the sync options, it is back to the defaults, and regular caches are not disabled explicitly. This allows data (file contents) to be written asynchronously (journal and metadata still synchronously I assume). The disadvantage of this is that more data could be lost in case of a sudden power failure. (This is only concerning the data being written at that point in time.)

Similarly, there's the async option to force writes to happen asynchronously. This is considered less safe, and should only be used if you need the extra performance it gains in your case. Stick with the defaults in case you're unsure.

Either way, the journal design of the filesystem will ensure data appearing present is not half-written or inconsistent by default. Returning from sync to the defaults is 'just safe' in these terms.

0

You must log in to answer this question.