0

I have a real-time application which always writes data to a RAID 10 HDD configuration in a sequential manner at around ~50 MB/s. It uses mmap and writing should never be blocked due to waiting I/O.

Then sometimes large burst of reading occurs, e.g. I want to read 500GB of sequential data as fast as possible from the drive. However, it may not cause the writing application to be I/O blocked.

We solve this currently by setting the writing application to SCHED_FIFO and then use CFQ I/O Scheduler + I/O nice on the reading applications. This works fine, but it is a bit inefficient as the drives need to do a lot of seeking back and forth to do both writing and reading.

I'm wondering whether there are any strategies to improve this? The system drive is a fast 256GB SSD drive. Could I somehow have Linux write to the SSD while there is space and reads are occurring? Is this achievable with e.g. bcache, dmcache or some other module? i.e. it would only write to the SSD while reads to the HDD are occurring and then later flush it out to the HDD. If the SSD cache is "full" then the writes to the HDD should have full priority over reads.

  • The occasional bursted reads, do they read the recently added data, or something older? – Marcin Nov 5 '15 at 15:10
  • The mdadm --write-mostly option might be of some help, to tell the md system that the spinning disk should mostly be used for writing, implying that the SSD is used mostly for reading. That's for RAID1 setups with one half of the mirror that has fast storage (e.g. SSD) and the other half slower storage (spinning disks). It could also be used when one half of the mirror is a DRDB network disk. – wurtel Nov 5 '15 at 15:32
  • @Marcin: They read older. – ronag Nov 5 '15 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.