4 ms·
Yes. It should be more in the order of 3 hours.
by trafficlight 17y ago
Yes. It should be more in the order of 3 hours.
- barrkel 17y agoPresuming the data is being backed up at the block level on the disk, so that no random seeking is involved. If it's on a filesystem basis, involves many small files, and we're talking spinning hunks of rust, 3 hours is a ludicrously optimistic estimate.
- jsolson 17y agoTime Machine can do it on a full 500GB filesystem in a little over 5 hours, in my experience. YMMV.
- barrkel 17y agoIs that an incremental backup, or the full backup? I would expect a full filesystem backup to be easier to do in block mode for large parts than only part of the filesystem, while incremental backups could be made much easier with filesystem support, such as what ZFS can do with the increment from one snapshot to another.
- Tuna-Fish 17y agoActually, since modern NCQ is pretty good, as long as the software issuing the read commands is smart and fills the queue, seeks are not going to slow you down that much. Naive implementation that only does serial IO and waits for last request to complete before issuing a new one will suffer brutally, though.
- barrkel 17y agoGetting all the pieces in the abstraction stack to work in the same direction with respect to I/O queuing is key, indeed. For example, does the NCQ work well with the USB mass storage device stack? I haven't looked into the moving parts in detail, but it's easy to see that the maximum speed is limited to the slowest and dumbest link in the chain.