Slashdot Mirror

← Back to Stories (view on slashdot.org)

bdflush - Streaming Buffer-to-Disk vs. Burst I/O?

Posted by Cliff on from the improving-your-throughput dept.

A not-so Anonymous Coward asks: "I'am trying to sustain major data input&output on a ftpserver. I have been tweaking with /proc/sys/vm/bdflush and buffermem settings, but the IO is still very bursty. Disks are IDE and use lots of CPU when the update decides to flush the dirtybuffers. The opions differ on the net, what can I do to leave some CPU to the NIC while for example 75% is doing the data-to-disk stream? I have read the Documentation/sysctl/vm.txt and /sysctl/proc and a couple of other hints, but no real improvements so far. Please include detailed motivations and maybe even test results."

1 of 11 comments (clear)

  1. Hdparm to the max by barneyfoo · · Score: 5

    I can help you with hdparm, but I'm not familiar with vfs tuning.

    Most others here suggest turning dma on, which is obvious, but there are many other things you can do with hdparm to help performance.

    This is the command I use on startup:

    hdparm -d1 -c1 -u1 -A1 -a255 -m16 -X66 -W1 /dev/hda

    -d1 -- turn on dma
    -c1 -- enable 32bit transfers (helps alot)
    -A1 -- enable readahead
    -a255 -- set readahead to 255 (maximum on ide drives)
    -m16 -- permits the transfer of multiple sectors per interrupt (16 in this case - max for my hd)
    -X66 -- set UDMA33 transfer mode. 67 is uata66, 68 is uata100.. dont bank on that, however.
    -W1 -- enable write cacheing (this would help you alot) make sure your hard drive is stable with all other settings before trying this, as it's dangerous.

    Also try getting the program powertweak for setting all kinds of tuning parameters. There is a powertweak-gtk with descriptive tooltips as well.