Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30813
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Multithreaded disk access |
| Date | 2021-10-18 01:09 +0300 |
| Organization | TGI |
| Message-ID | <ski6vd$hf1$1@dont-email.me> (permalink) |
| References | <skc214$tm7$1@dont-email.me> <ski0v5$7iu$1@dont-email.me> <ski5q2$77e$1@dont-email.me> |
On 10/18/2021 0:49, Don Y wrote: > On 10/17/2021 1:27 PM, Brett wrote: >> Don Y <blockedofcourse@foo.invalid> wrote: >>> As a *rough* figure, what would you expect the bandwidth of >>> a disk drive (spinning rust) to do as a function of number of >>> discrete files being accessed, concurrently? >>> >>> E.g., if you can monitor the rough throughput of each >>> stream and sum them, will they sum to 100% of the drive's >>> bandwidth? 90%? 110? etc. >>> >>> [Note that drives have read-ahead and write caches so >>> the speed of the media might not bleed through to the >>> application layer. And, filesystem code also throws >>> a wrench in the works. Assume caching in the system >>> is disabled/ineffective.] >>> >>> Said another way, what's a reasonably reliable way of >>> determining when you are I/O bound by the hardware >>> and when more threads won't result in more performance? >> >> Roughly speaking a drive spinning at 7500 rpm divided by 60 Is 125 >> revolutions a second and a seek takes half a revolution and the next file >> is another half a revolution away on average, which gets you 125 files a >> second roughly speaking depending on the performance of the drive if my >> numbers are not too far off. > > You're assuming files are laid out contiguously -- that no seeks are needed > "between sectors". This is the typical case anyway, most files are contiguously allocated. Even on popular filesystems which have long forgotten how to do worst fit allocation and have to defragment their disks not so infrequently. But I think they have to access at least 3 locations to get to a file; the directory entry, some kind of FAT-like thing, then the file. Unlike dps, where 2 accesses are enough. And of course dps does worst fit allocation so defragmentating is just unnecessary. ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-15 07:08 -0700
Re: Multithreaded disk access Richard Damon <Richard@Damon-Family.org> - 2021-10-15 11:38 -0400
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-15 09:00 -0700
Re: Multithreaded disk access Richard Damon <Richard@Damon-Family.org> - 2021-10-15 12:48 -0400
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-15 11:40 -0700
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-15 18:46 +0300
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-15 09:19 -0700
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-15 19:28 +0300
Re: Multithreaded disk access Brett <ggtgp@yahoo.com> - 2021-10-17 20:27 +0000
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-17 14:49 -0700
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-17 15:01 -0700
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-18 01:09 +0300
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-18 08:05 -0700
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-18 19:25 +0300
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-18 13:46 -0700
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-19 00:46 +0300
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-18 16:17 -0700
Re: Multithreaded disk access antispam@math.uni.wroc.pl - 2021-10-31 19:21 +0000
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-31 21:55 +0200
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-25 04:19 -0700
Re: Multithreaded disk access Richard Damon <Richard@Damon-Family.org> - 2021-10-25 20:23 -0400
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-25 22:29 -0700
Re: Multithreaded disk access Clifford Heath <no.spam@please.net> - 2021-10-18 11:58 +1100
csiph-web