Home/ Questions/Q 4027378
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T11:05:22+00:00

I’m interested in some low-level details on how disk seeks and writes works when

  • 0

I’m interested in some low-level details on how disk seeks and writes works when your working with two files concurrently.

I’m thinking of splitting an file that I currently do both read and writes on to two files to handle concurrency better. They’re are potentially heavily accessed at the same time.

a) Will performance be much worse because two files are accessed instead of one, even if disk seek times would from the start to the end of a big “all-in-one” file?

b) Can you somehow place two files after each other or “close to each other” on disk to improve their concurrent performance? (I guess this will be hard with disk fragmentation and all)

c) How does SSD drives affect this, since they don’t spin they should be pretty good for a solution like this right?

d) if you fire rapid i/o reads and writes at both files at the same time will the OS (Windows) optimize so that the disk the head doesn’t go back and forth too much?

I’m bit curious why some database/nosql solution seem so adamant in keeping things in a single file when using more than one seems to offer some advantages.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    a) No, the overhead is pretty much the same as if they were a single file.

    b) Not really, unless you know your usage pattern pretty much exactly. You can use FSCTL_MOVE_FILE in Windows if you need to move your files around, but I don’t recommend it because (1) you’d need administrator privileges, and (2) it’s really hard to figure out where to put the file, because each disk has different specs, and because you might end up having to basically build your own defragmentation engine.

    c) Yes, SSDs are the perfect solution to this! 🙂

    d) Native Command Queuing within the disk is designed to allow for this on SATA drives (it reorders up to 32 commands by the OS for better performance), and while it’s definitely helpful, it’s not quite as noticeable of a gain as you might think. The file system’s memory cache is a much more influential factor here — it caches your data in memory so that random writes can become more sequential (and faster).

    • 0