Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 1 down vote favorite

I've recently scaled back my home network, with one of the bigger changes being a switch-over to using a BD-RE drive for backup. With years of pictures and home video consuming about 25GB, and [important] documents well under 10GB, this SEEMED like a great way to go.

Everything WORKS perfectly, my only concern is the overhead. I have the disc formatted UDF, and a script running rsync nightly to sync up selected paths in the filesystem to the drive.

During the sync, My CPU(s) are showing roughly 25% in the wait state. This wouldn't be so bad, but it STAYS at this level for a very long time, and in the process, slows everything down to a crawl. I've even observed my load average spiking to 15.9+ (on a Core 2 Quad). The "actual" CPU utilization during this time is only around 6% (ALL VMs combined), so this is strictly an I/O bottleneck.

Documentation specific to Blu-Ray burners is scarce (under Linux) compared to everything else, and I've never had an I/O bottleneck high enough to warrant any in-depth analysis. Considering the drive is burning at 2x (~9MB/s), it should complete in roughly an hour, but instead runs for many hours.

Is there any way to optimize this to reduce the wait states? Am I simply constrained by kernel drivers/hardware/??? Is this just a nasty side-effect of using UDF that I'm unaware of? Could this have anything to do with running 3 VMs (2x Windows & 1x MythTV) as well as NFS along with this process? Is there any way to determine with certainty which piece of the puzzle is the problem?

Sorry for the barrage of questions at the end; any help is greatly appreciated.

EDIT: After the answer from psusi, I had a thought; is there a way to prioritize I/O on a per-device basis? Something along the lines of "guaranteed XXX PCI card 1MB/s", "limit XXX block device to 20MB/s", etc.???

share|improve this question

1 Answer

up vote 1 down vote accepted

The wait time is normal. Wait means that the cpu is not busy, but could be if a program ( rsync ) were not waiting for disk IO ( writing to the slow blueray ). It is 25% because you have 4 cpus, and rsync could only be using one of them ( 1/4 = 25% ), if it were not waiting on the disk.

As for the overall throughput being low, that is because rsync has to first read the file from the disc, compute checksums, read the file from the hd, compare, figure out what changed, and then write any changed parts. All that time spent reading is going to slow things down.

rsync is really intended for moving data over a slow network between two fast hard disks, not to a read/write mounted udf optical disc. You would be better off using a conventional backup system like tar.

share|improve this answer
I certainly understand the 25% being 1 of 4 cores, and I guess I hadn't put much though behind the overhead of rsync. I still have a hard time believing that the low throughput of the BD-RE drive could completely lock up ALL I/O on the system. It just feels like maybe I have a setting somewhere incorrect (I know it's SATA, but in the IDE days there were DMA settings/etc.). I just checked my MythWeb "recordings" page, and EVERY recording during the period it was running was trashed. The card has a HW MPEG encoder, so it uses very low I/O (~600KB/s), but the BD drive completely took over. – Gregory Hoerner Sep 29 '11 at 3:05
Sometimes the simplest answer is the best one; I had to accept this for suggesting using something different. After switching from rsync -tr to cp -ur, although the wait state on the 1 core was still 100% (25% total), the system no longer comes to a grinding halt. Apparently the overhead of rsync took it over the top. Best of all, my MythTV VM was able to successfully DVR a show while it was running without a hiccup! (I lose some minor functionality in the switch, but I consider it a worthwhile tradeoff). – Gregory Hoerner Sep 29 '11 at 4:16
1  
@Gregory Hoerner, It certainly shouldn't be messing up recordings to the HD, unless the HD is particularly slow. It obviously will be putting some load on the HD as it reads the source files and computes the checksums, but shouldn't be that bad. – psusi Sep 29 '11 at 13:44
@psusi... I had the same feeling. They're Hitachi 2TB/7200RPM/64MB drives, with that particular partition being a RAID 0 stripe of 1/3 of the two (1.4TB). Not blazingly fast, but certainly not slouches. Don't worry, all of my critical stuff is on a RAID 1 partition; I actually mounted this space as /unreliable, and only use it for holding DVR'd shows and stuff I can readily download again. – Gregory Hoerner Sep 29 '11 at 15:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.